Buying vs building your own osquery solution

Buying vs building your own osquery solution

Jason Meller by Jason Meller on

In this article, we compare the various difficulties and costs associated with trying to build your own osquery solution vs buying 1Password’s osquery-based device trust product.

When you’re making the case for your company to buy 1Password® Extended Access Management, executives and technical procurement managers will inevitably ask if you’ve considered alternatives. And since 1Password Extended Access Management’s Device Trust solution uses osquery, an open-source software, you should expect that one of those proposed alternatives will be building it yourself.

This should be no surprise; osquery is the most popular open-source endpoint security project on GitHub. So it’s reasonable to ask: how much value is 1Password’s Device Trust solution really providing on top of it, and how much can I get by just making my own solution?

In this article, we are going to cover the differences between our solution and vanilla osquery on its own, and explore what it would take to replicate some of the features 1Password Extended Access Management provides.

Why does 1Password Extended Access Management use osquery?

Before we get into build vs buy, let’s take a moment and explain why 1Password Extended Access Management uses osquery in the first place.

At its core, our device trust solution is intended to cover three primary use cases:

  • Achieve compliance. Measure, achieve, and maintain your compliance goals.

  • Obtain visibility. Obtain complete fleet visibility across Mac, Windows, and Linux endpoints

  • Implement honest security. Make security a core value in your company’s culture.

To help your organization accomplish each of these use cases, 1Password’s Device Trust solution needs an endpoint agent that can collect the necessary telemetry required across Mac, Windows, and Linux devices without hurting performance.

On top of that, we’re committed to end user privacy and transparency. With that in mind, we wanted to ensure that the source code for all the binaries we ship to the endpoint could be scrutinized by our customers and end users.

Given all of these requirements, osquery was the only open-source tool out there that fit the bill. Even so, it’s easy to forget that osquery is a means to an end, not a complete solution itself.

While osquery is a great fit for our use case, there are a few things it doesn’t do out of the box, which are prerequisites needed by any organization before they can roll it out and manage it competently. This is why we created Kolide Launcher, our own agent that wraps around osquery, extending its data collection capabilities, providing native installation packages, and most importantly, solving the problem of automatic updates.

Osquery architecture & deployment

How to deploy osquery on your own

For your in-house osquery solution to work at all, you need to get it onto devices. To do that, you’ll need tools like Chef, Puppet, or Ansible to distribute not only the osquery binary itself, but also its configuration file and any future updates to that file.

From there, the data osquery provides isn’t automatically neatly arranged. Below is an example of a query result for a single device run in a format known as snapshot, a mode where each time the query is run, the full results are emitted to a log with some additional metadata about the device.

{
  "action": "snapshot",
  "snapshot": [
    {
      "parent": "0",
      "path": "/sbin/launchd",
      "pid": "1"
    },
    {
      "parent": "1",
      "path": "/usr/sbin/syslogd",
      "pid": "51"
    },
    {
      "parent": "1",
      "path": "/usr/libexec/UserEventAgent",
      "pid": "52"
    },
    {
      "parent": "1",
      "path": "/usr/libexec/kextd",
      "pid": "54"
    }
  ],
  "name": "process_snapshot",
  "hostIdentifier": "hostname.local",
  "calendarTime": "Mon May  2 22:27:32 2016 UTC",
  "unixTime": "1462228052",
  "epoch": "314159265",
  "counter": "1",
  "numerics": false
}

This is in contrast to the differential log format, which instead of showing the full result set of a query run, shows only the differences between the current query run and the previous query run. When logging results in the differential logging format, it’s up to you to assemble the final state.

{
  "action": "added",
  "columns": {
    "name": "osqueryd",
    "path": "/opt/osquery/bin/osqueryd",
    "pid": "97830"
  },
  "name": "processes",
  "hostname": "hostname.local",
  "calendarTime": "Tue Sep 30 17:37:30 2014",
  "unixTime": "1412123850",
  "epoch": "314159265",
  "counter": "1",
  "numerics": false
}
{
  "action": "removed",
  "columns": {
    "name": "osqueryd",
    "path": "/opt/osquery/bin/osqueryd",
    "pid": "97650"
  },
  "name": "processes",
  "hostname": "hostname.local",
  "calendarTime": "Tue Sep 30 17:37:30 2014",
  "unixTime": "1412123850",
  "epoch": "314159265",
  "counter": "1",
  "numerics": false
}

If you want to compile or export that data, you’ll need tools beyond osquery itself. Here’s a diagram showing one example of the free (more accurately, “freemium”) tools that you would need.

A graphic showcasing the freemium tools and programs you'll need to export this desired data.
You need to deploy more than just osquery to make use of its abilities.

It’s worth noting that, as you do your research, you may encounter what appear to be free and open-source tools that work with osquery and extend its capabilities. But some are actually paid products with a free tier, while vital features are locked behind subscriptions.

Other tools are just outright expensive. For instance, osquery itself can directly connect to popular data streaming services like Amazon AWS Kinesis Streams, which can cost $10,000 to $20,0000 a year alone. And to use it, you’d need to set up an osquery management server that implements Osquery’s remote TLS API. There are many paid management servers. There are also free (and freemium) servers that you can host on your own infrastructure. But either option will also require time and headcount to manage and maintain those servers, and updates will pose their own problems.

How 1Password’s Device Trust solution deploys

As you are likely already aware, 1Password Extended Access Management is a SaaS product. In this context, that means we host all of the centralized infrastructure that your endpoints send telemetry to on a regular basis. Hosting isn’t just turning on a web server–it includes:

  • Regularly applying security patches.

  • Automatically scaling the environment.

  • Ensuring the service remains highly available.

  • Safely storing the data devices send to us.

When it comes to rolling out the agent to devices, we wanted to make this as simple for you as possible. This is why we pre-build native installation packages on Mac (.pkg), Windows (.msi), and Linux (.deb and .rpm).

These native packages are perfect for distribution via MDM software such as Jamf and Microsoft Intune. Since they are signed and notarized, end users won’t see any worrying prompts about untrusted code. As soon as the package is run, the agent automatically connects to the application without any further action needed on your part.

If you don’t want to use MDM software to distribute the agent, you can use our onboarding feature to reach out to end users directly and guide them step-by-step through the process of installing the agent. You can even automatically message new employees on their first day to guide them to self-install the agent.

It’s a simple process, and as soon as it’s installed, you’ll immediately have visibility into each device’s posture and compliance according to the data compiled by osquery.

Dealing with annual OS changes

Given Apple’s success with shipping annual OS updates, even OS vendors like Microsoft (despite their reputation for changing Windows at a glacial pace) are doing everything they can to substantively change their OS at a faster rate.

If you build your own solution, these annual releases (and the shorter and shorter beta cycles that precede them) are extremely disruptive to tools like osquery, which rely on private and undocumented APIs to get the critical data you need.

Since osquery often relies on unsupported APIs to gather data, many queries that work in one OS version and CPU architecture can suddenly and inexplicably stop working after even a minor upgrade. There is no better example of this than the macOS screenlock feature that was completely rewritten in macOS 10.13. Fixing it required reverse engineering an undocumented API, and the development of a new osquery capability.

To resolve these situations, the operators of your solution will need to regularly test your osquery SQL queries against the latest development and beta releases as soon as they’re available.

Meanwhile, at 1Password, we have a dedicated team of engineers that think about this problem. They participate vigorously in the osquery open-source project and collaborate with OS vendors to ensure our app works correctly on day one of an OS' official release.

Configuring the data you collect

One of the largest misconceptions about vanilla osquery is that once you’ve rolled it out, it will automatically measure your device’s compliance. The truth is, osquery is only as good as the queries you run and the tools you use to analyze its data.

With vanilla osquery, it’s on you to:

  • Develop/find SQL queries that will help you measure your compliance objectives.

  • Add those queries to the osquery schedule in the configuration.

  • Aggregate the data to produce a meaningful report.

While the official osquery project does provide example query packs, most of the packs have not been updated for years. For example, the vast majority of threats in the Unwanted Chrome Extensions Pack are from over four years ago and reference extensions that are no longer distributed in the Chrome Extensions store.

In contrast, 1Password Extended Access Management comes prepackaged with over one hundred checks (specially written osquery SQL queries) that, when run on a device, produce an accurate attestation of that device’s state. 1Password Extended Access Management aggregates these check results in a dashboard so you can track how well you are doing across your entire fleet. If there isn’t a check available for your needs, you can also write a custom check using our templates or starting from scratch.

Finally, 1Password’s Device Trust solution’s most unique feature is its ability to aggregate, persistently store, meticulously document, and make programmatically available thousands of data points about each enrolled device. Not only do we do this at no additional charge, we allow you to query the database this data is stored in with SQL.

Putting osquery data to use

To reiterate, osquery’s main function is to gather data about device states. But while it’s great to unearth a lot of scary problems in your environment, the other half of that equation is having a way to remediate them, and there are plenty that cannot be fixed with automated tools like MDM. Those tricky issues can quickly spiral into an emergency situation where end user remediation will be an essential feature.

1Password Extended Access Management integrates with SSO providers like Okta and Microsoft Entra to ensure that only healthy devices can access company systems. If a device fails a regularly scheduled query – for instances, the user’s chrome browser isn’t updated – our agent tells the user:

  1. What the problem is.

  2. Then, it provides detailed self-remediation instructions on how to fix the issue.

  3. Then, it tells the user that they will be blocked from authenticating if they don’t fix it by a certain deadline.

End user-driven remediation of nuanced problems is our core use-case. To enable it, we’ve put a lot of work into building out our SSO integrations to make sure that the data gleaned from osquery can be put into action to keep your systems safe. These consequences make our solution a fully-fledged device trust offering.

If you are attempting to replicate 1Password Extended Access Management’s self-remediation features, you’ll need to contend with differentiating instructions between OS versions as features are removed, added, and altered throughout the OS.

Building this integration on your own would pose a lot of challenges. For starters, you’d need to be able to associate end users with their osquery installation. This sounds easy, but often requires some sleuthing and automatic assignment based on evidence collected from the device itself. Without an osquery management server that is end user aware, you will need to build this understanding yourself in order to gain much security from your osquery build.

Key Takeaways

This was a lot to absorb, but my hope is you take away the following key points when comparing the cost of buying 1Password Extended Access Management to building everything yourself with osquery.

The main thing to take away is that osquery, at its core, is a simple producer of telemetry. To make use of it, you need additional tools, time, and headcount to get it onto devices, fit its data gathering capabilities to your needs, and to keep it up-to-date.

No matter if your use-case is fleet visibility or compliance, there are several ongoing costs you’ll need to consider if you plan on building your own product. These costs might not be obvious for newcomers to osquery, but become relevant quickly when you try to put it to work.

With 1Password Extended Access Management, you can easily view and export logs (if you want), and we also give you intuitive visualizations about what’s going on inside a device, highlighting and calling out the things that matter. And we go beyond visualization alone, with the assurance that devices that aren’t healthy won’t be able to authenticate. That can see huge rewards and savings for compliance reporting alone.

It might not be free, but we are a fully-featured product packaged under straightforward pricing. As you think through alternatives, it’s important that you consider their true costs, not just during the experimentation phase, but when they are fully deployed in a production setting.

We built this product because we saw so much promise in osquery, but found the only organizations who could enjoy it were the ones who had the technical know-how and enormous budgets to operationalize it safely and effectively. We made a big bet that if we built software to dramatically reduce the complexity, risk, and toil needed to tap into that promise, more organizations would be able to experience the value that osquery offers.

We strongly believe we’ve built something compelling and, when analyzed honestly against building it yourself, we’re the obvious choice for nearly all organizations.

Want to see our osquery device trust solution in action? Reach out for a demo!

VP, Product Management

Jason Meller - VP, Product Management Jason Meller - VP, Product Management

Tweet about this post