Two of the 6 basic security controls, according to the Center for Internet Security, are focused on the current state of your assets. Assessing the state of your assets has been a priority for years, but the old means aren’t as effective in modern infrastructure as they were on legacy systems.
These two critical controls - Continuous Vulnerability Management and Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers - are a foundational part of any security program, but you’ll run into implementation challenges if you simply drag legacy tools into a cloud environment. That’s why osquery, a light weight and cloud friendly universal agent, is quickly becoming the go-to for helping to secure cloud workloads, in part through the effective application of these two critical controls. Let’s explore how.
Forgive my pedantry here, but continual vulnerability management, or scanning your network once per quarter and dumping a giant report on IT’s desk, was the bare minimum to satisfy regulators for years. Continuous vulnerability management, as CIS [and any security expert] suggests, requires a lot more. It’s a constant cycle of:
The big reason to highlight this differentiation for cloud workloads is that old assumptions that your servers remain the same for many months are no longer relevant. New methods are needed to ensure that data is being collected from every host when it comes online or risk never assessing the vast majority of cloud workloads.
One of the most beautiful characteristics of osquery is that it just waits for you to tell it what to collect. If you’re using it in your cloud, osquery is already collecting an incredibly diverse set of data from your assets and that likely includes which packages are installed. Given this information, you can take a database of known vulnerable packages for the asset’s operating system, compare to it, and have a list of vulnerabilities to remediate.
To truly reach continuous assessment, include osquery in your base image and every asset will be assessed for vulnerabilities seconds after coming online. This simple action will take your cloud environment from the worst-assessed in a periodic scan approach to the best-assessed. In fact, when new vulnerabilities are published, historical osquery data is useful to list of any assets which were online and vulnerable, no matter their current state. Instead of only having a periscope you can periodically push up to the surface to scan for ships, you have a continuous stream of sonar readings to show you as soon as ships enter your environment.
Though the numbering changed slightly (in version 7), what hasn’t changed is the importance of establishing baselines for how your systems should be securely configured. If you’re using public cloud service providers for Infrastructure-as-a-Service (IaaS) or Containers-as-a-Service (CaaS), then you are using someone else’s hardware and can focus on the software configuration. The CIS benchmarks are a set of well-trusted and prescriptive guides here. There are always going to be some which are irrelevant to your organization, but using their guidance to define gold images is the best way to ignite your system hardening efforts.
But the challenge with configuration compliance for most organizations is not the initial definition of gold images -- it’s identifying and resolving the assets on which those gold images have decayed. Everyone dreams of having their cloud’s assets never stray from the gold image state, but day-to-day operations are nearly guaranteed to cause otherwise. So you need to check, just as continuously as you do for vulnerabilities. Which, once again, presents a problem for monitoring your cloud assets: legacy CIS benchmarking tools are not designed to plug directly into today’s elastic compute environments.
An occasional misconception heard about osquery is that to use it for compliance, you must simply assign the open source “it-compliance.conf” query pack to the assets which are in scope.
This couldn’t be less accurate. That query pack is an excellent example of valuable data sources for collecting compliance evidence, but the results of that query pack’s queries need an established baseline (like CIS benchmarks) for desired states. It’s like setting down a bag of groceries and calling it a gourmet meal -- there’s still a lot of work to be done.
While these benchmarks are available to the public, and augeas lenses can get you access to the more obscure configuration settings, you still need to grade the results. What constitutes a compliant result? To what should the collected data be compared? The raw osquery data you collect needs to analyzed against the desired settings for each benchmark to identify which cloud assets have strayed from the gold image. Done manually, this legwork is daunting, so some level of pre-built analytics are highly suggested.
The assets running in your cloud aren’t the old school servers down the hall. Even if you can access them with your legacy security tools, you would likely prefer otherwise. Osquery can get you the cloud workload data you need to answer a lot of the key vulnerability and configuration questions; Uptycs analyzes this data to power its Compliance and Vulnerability dashboards and reports continuously, so you can immediately identify when the gold image of one of your hosts has strayed from its baseline. Connected assets will be automatically analyzed to help you prioritize the highest risk, oldest, and most prevalent vulnerabilities in your environment. We call it dead simple audit and compliance and you can see it in action by scheduling a demo.
An example of Uptycs Vulnerability Dashboard, available in the Uptycs Security Analytics Platform.
Related osquery resources: