Last week we announced the 7th milestone release of Twistlock (Twistlock 1.6). For those of us that have been here from the start, it’s a little hard to believe that less than a year ago, we shipped Twistlock 1.0 and that now we have more than 30 paying customers across 4 continents, from all kinds of industries, including government, defense, healthcare, finance, and media. We take pride in doing customer focused engineering and being real partners to our customers and this release is a great example of that. In addition to being packed with a lot of new functionality, many of these new features are direct customer requests.
This blog goes through a few of the highlights from this release. To download 1.6 or for help with the new features, you can always visit your support portal (support.twistlock.com) or talk to your Twistlock account team.
— John Morello & the Twistlock R&D team
In 1.6, we’re continuing to add to our runtime capabilities with the first iteration of a new feature we call Runtime Radar. As we build the predictive models used to protect your containers at runtime, we create a detailed data set of not just the images, but also how those containers running them interact with each other. The radar feature is the first iteration of making this data available in a more visual way.
In 1.6, Runtime Radar is primarily focused on networking capabilities. You’ll see a dynamically generated mesh topology that shows all the running images in your environment and how they interact with each other from a network standpoint. This graph is generated directly from our runtime data set, which means you don’t have to manually provide it with any data, nor do you have to make any changes to the way you deploy your containers. Additionally, in 1.6, you can draw connections between these objects which are imported into the runtime mode. For example, if you have a front end web server container and a backend database, you can create an implicitly allowed data flow between them by drawing a line between the two and specifying the allowed ports. Twistlock will then use this rule while monitoring for runtime anomalies.
In previous versions of Twistlock, we supported a high availability model that was dependent upon an external MongoDB cluster. While effective, this approach required customer effort to setup and knowledge of MongoDB to operate over time. In 1.6, we’ve made this far easier with a new ‘simple HA’ feature.
In 1.6, clustering is built in and completely self contained within Twistlock. For customers that want to enable HA functionality, it’s a simple matter of deploying additional Consoles using a simple graphical workflow in the Twistlock UI. Internally, we manage all of the cluster setup, leader election, and failover, so all you need to do as a customer is turn it on and put it behind a load balancer.
Note that HA is still an optional configuration; for customers that do not require it, the Console can still run in a standalone mode with a ‘fast recovery’ option.
Webhook triggered scans
Fast, efficient scanning for vulnerabilities has been a part of Twistlock from the start and we continue to invest in new features, like the catalog API we added in 1.5, to make it even faster and easier for customers. In 1.6, we’ve added support for webhook triggered scans that makes scanning images registries happen literally as soon as the image is pushed.
Before this feature, image scanning on registries was a time triggered event. At a customer defined interval (every 24 hours by default), Twistlock would discover metadata about the registries, optimize for only looking at net new images or updates, and scan those new and changed images. In 1.6, you can use standard Docker Registry webhooks (https://docs.docker.com/registry/notifications/) to kick off targetted scans on every push. In this model, as soon as your registry has a new build pushed to it, it will notify Twistlock of the updates image and Twistlock will scan it immediately, so your image scan results are just as fresh as what’s on the registry itself.
Note that this feature requires that your registry supports the webhook feature. It’s also completely optional and additive; all the existing scanning functionality on registries and via our CI plugins is still available.
When Twistlock scans images for vulnerabilities, we’re looking not just for known CVEs, but now also 0-day vulnerabilities. Twistlock partnered with Exodus Intelligence (see the blog announcement at https://blog.exodusintel.com/2016/07/27/twistlock-and-exodus-partner-to-identify-apps-with-zero-day-vulnerabilities-in-your-containers/), a prominent independent security research firm, to include Exodus’s 0-day feed in Twistlock’s Intelligence Stream. Exodus’ research space is broad, including IoT scenarios, traditional enterprise software, as well as open source components often found in container images, such as MySQL and Apache.
When Twistlock detects a component in an image as being vulnerable to a 0-day they’ve discovered, we’ll alert on it and show summary details on the nature of the flaw. Additional low level details, including sample code, can then be obtained directly from Exodus. Here’s an example of a 0-day detected in a Java component:
Notably, no additional steps are required for you to benefit from this detection; it’s included in your existing subscription and happens automatically in every scan beginning in the 1.7 release.
Risk Tree API
When a new critical vulnerability is discovered, organizations often need to be able to quickly identify the scope of their exposure. Similarly, you may want to be able to easily determine whether a particular fix has been built and the new image deployed in across your environment. Because Twistlock knows about the state of all the images across the environment and because our runtime dataset includes mappings of images to containers and containers to hosts, we can provide this information easily in a structured format.
That’s the function of the Risk Tree API. You provide a set of CVEs to Twistlock and Twistlock provides back an ordered tree of what images include those vulnerabilities, what containers are running those images, and what hosts are running those containers. This allows you to automate, with a single API call, the creation of a detailed map of your exposure to the vulnerabilities.ww
For example, if you provide Twistlock with a list of CVEs like this:
“cves”: [“CVE-2014-6271”, “CVE-2015-6271”, “…”]
Twistlock will reply with this:
“cves”: [“SUBSET OF PROVIDED CVES, RELEVANT TO THE IMAGE”]
“cves”: [“SUBSET OF PROVIDED CVES, RELEVANT TO THE IMAGE/CONTAINER”]
“imageIDs”: [“SUBSET OF THE IMAGE IDS ABOVE, THAT EXISTS IN THE HOST”],
“cves”: [“SUBSET OF PROVIDED CVES, RELEVANT TO THE IMAGES”]
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Your Firewall’s Role in Cloud-Native Security
We live in the cloud-native era. That means the firewall strategy that...
Compliance, Microservices and Your Application
Compliance in modern applications that leverage containers, serverless...
6 Tips for Secure Data Management for Containers
One of the main reasons why containers have become so popular is that ...
OpenShift Internal Registry: Populating Registry Scans with Twistlock
Twistlock uses the Docker v2 Registry catalog API call to inventory im...
Better Together: Protecting Docker Registries with Twistlock and JFrog Artifactory
In a containerized devops lifecycle, a registry such as JFrog Artifact...