Checks have been a part of Kolide since our product’s debut in 2019. They are the building blocks that allow you to determine if a device you manage is in a trusted state. Not only that, they allow you to direct your end-users’ attention to problems on the device so they can fix them.
As important as Checks are, Kolide has never allowed our customers to build them on their own. There is a simple reason for this: writing Checks well is really hard to do. Kolide staff use a multitude of tools to do this internally and it’s taken us years to hone the process. But recently, we felt we finally got it down to a science and could distill all of the elements into a single powerful authoring feature.
We had several design goals for this feature. First, we wanted to build an editor where customers who already comfortable writing Osquery SQL queries could have unlimited freedom in building any Check they wish. But more importantly, we also wanted the editor to be approachable by folks who don’t know how to write any SQL (Osquery or otherwise). To accomplish this, we wanted to include powerful templates for automatically generating Checks for our most requested use-cases including:
- The ability to locate sensitive files on an end-user’s device via Spotlight
- Require that a specific app be installed and running
- Prohibit a specific app from being installed
Starting today, we’re finally ready to show you what we’ve been up to. I am extremely proud to introduce to you our Custom Check editor.
Let me walk you through it.
To write your first Custom Check, you simply click The Add New Check button on the Checks page. In addition to the Check Catalog, we now have a new tab called Build Your Own which allows you to start the Check writing process.
To demonstrate the editor, we are going to delve into a common use-case; preventing Shadow IT (informing end-users that installing certain software is not permitted.) For example, let’s say we really don’t want employees to use Dropbox on their company device–how would we build that Check?
First, we choose the Prohibit macOS App template and fill it out accordingly:
Once the form is submitted, we are whisked away to a fully-featured editor.
The editor breaks down the Check writing process into four distinct steps:
Writing and testing the query that runs on the Kolide Endpoint Agent
Adding details used to display the Check in the catalog
Authoring the notification text that will be sent to employees (if you choose to enable end-user notifications)
Supplying the required privacy details so end-users can understand what the Check does in the Privacy Center
One thing I really like about the SQL writing section is, even though we started from a template, we can still update the template form fields and the SQL query will get regenerated for us. We really don’t need to know any osquery SQL at all.
That said, the really powerful feature is testing your Check against existing enrolled devices. This allows us to hone the Check’s logic and make sure it returns the expected results across our devices before we decide to publish it. To run a test, you simply select some test targets and click Test Run.
Any data returned from a Test Run can be added to the example data set, which you can use to test build a collection of representing failure scenarios. We can also edit or create example data from scratch if no representative results are returned. Later, we can use these scenarios to test any dynamic portions of the end-user notification.
Next, let’s spruce up our notification text that we will send to end-users. While the default text from the template is fine, it’s not very descriptive. To practice good Honest Security, we really want to tell them the why in the rationale. With the editor this is really easy; we can type in the text box and see a preview update live as we write!
If we wanted to include more dynamic elements (via liquid templates) and test those, we could do that as well by editing the data in the example failure.
Since we are using a template, we can skip the other tabs (the green checks next to them show us they are already good to go) and publish our check right away.
That’s it! No seriously, we’re done. We now have a Check that has all the same features as any official Check that Kolide ships out of the box. Not just that, we can edit this Check anytime we want. For example, if we wanted to expand the query to add another Bundle ID, we simply click edit and our Custom Check Draft is immediately re-instated (with all of our test data still preserved).
When we go to publish this time, Kolide will show us a helpful side-by-side diff so you can be confident in the changes.
As you can see, there is a lot going on with this editor–far too much for us to cover in a single Changelog post. Rest assured, we’ll be writing more about this in the future but the best way to really get a feel for Custom Checks is to try it out for yourself. More importantly, we really want to hear feedback and suggestions on how we can improve this editor further. This thing is brand-spanking new and we could use your help further refining it and adding even more helpful templates for common use-cases. Hit us up via the chat widget in the bottom-right corner of Kolide, or, simply message us at firstname.lastname@example.org.
And if you are not a Kolide customer yet, what the heck are you waiting for? Sign up for a free trial and see what you’re missing.