I was recently meeting with a security director at a large web company, someone responsible for securing containers running across thousands of hosts. We were talking about all the great things Twistlock does to help with vulnerability management, and he brought up an interesting scenario. He said “All the visibility and policy enforcement you provide is great, but one of our challenges is understanding how exposed we are when a new high severity vulnerability is discovered.”
We’ve heard variants of this question before (often times, customers use a term like “when the next Heartbleed comes out”), and that’s why we built the new Vulnerability Risk Tree API that’s in Twistlock 1.6. Recall that Twistlock is looking for vulnerabilities across all the places your images are, throughout their lifecycle. We’re looking for them not just in your official repos, but also from the very start of their lifecycles in the CI process as well as in every image on every host we protect. Vulnerability findings are correlated to image digests and collected in the Console such that as soon as we’ve scanned the image once, the entire environment we protect knows about its vulnerability posture, and can enforce any rules you’ve defined without having to scan it again. Also, remember that our runtime protection is tracking every container across every host in your environment, so not only do we know what vulnerabilities are in your images, we also know what containers are running them.
The Vulnerability Risk Tree API brings all this data together in a simple REST endpoint so that you can easily respond to comments like the one the security director asked me recently. Specifically, given a vulnerability (or a set of vulnerabilities), tell me all the places I’m exposed. Twistlock takes the CVEs you provide and determines which images are impacted by them, which containers are running those images, and which hosts are running those containers, across your entire environment – regardless of what orchestrator or cloud platform you’re running on. This makes it easy to quickly assess how exposed you are to a vulnerability and quickly identify what you need to do to mitigate it.
For example, even in a large scale environment, the number of active images is often relatively small, particularly in environments optimized for running specific apps, like analytics or SaaS companies. In these environments, the same image may be reused in many different operational tasks, either directly or by being the base layer used to create slightly customized variants. This means that you can often mitigate vulnerabilities simply by rebuilding these core images and redeploying. The Risk Tree API helps you identify exactly what images are vulnerable, where they’re deployed, and the prevalence of deployment. Let’s take a look at how it works in more detail.
For this blog, I have a small lab running in our GCP environment. It’s a single host, but the only difference that makes is that the API will return fewer hosts exposed to the risk. I picked a CVE, CVE-2005-2541, that’s unpatched in the default Debian image, even though the NVD rates its severity as high. Because many images are built on this base, it’s a good illustration of how the risk tree works.
First, I authenticate to Twistlock and get a bearer token:
Next, I use that bearer token to authenticate to the risk API and pass is the CVE to query for and dump that out to a json file. Note that I can pass multiple CVEs together in the same call.
Let’s look at the JSON:
Curl is a great tool but it doesn’t produce pretty JSON output! Luckily, there’s a great Python tool for this, so let’s use that to make things easier to read:
Note that the API returns all the affected images (from the above screen snip), as well as all the containers they run in:
And all the hosts those container are on:
In this lab, I only have the single host, but if I had many hosts exposed to this risk, they’d all be listed here.
As you can see, the Vulnerability Risk Tree API makes it very simple to understand all the places you’re exposed to a given set of CVEs so that you can more effectively and safely prioritize mitigating them.
- Container Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Key Differences in Security, Management for Serverless vs. ContainersRead the Blog
Docker vs. KubernetesRead the Blog
How Cloud Workload Protection is Different than Application SecurityRead the Blog
Zero-Trust Security: What It Means and How to Achieve ItRead the Blog
Service Mesh. Service Fabric. Service Bus. What Does It All Mean?!Read the Blog