We’re happy to announce Twistlock 1.7. This is our biggest release yet, with major new capabilities around runtime, vulnerability management, and automation, as well as many UI enhancements throughout. In the blog post below, you’ll see an overview of some of these features and if you’d like to see more, we’d be happy to schedule a demo.
New Runtime Defense architecture
Runtime defense is the set of features that provides both predictive and threat based active protection for running containers. For example, predictive protection includes capabilities like determining when a container runs a process not included in the origin image or creates an unexpected network socket. Threat based protection includes capabilities like detecting when malware is added to a container or when a container connects to a botnet.
Twistlock introduced runtime defense in all the way back in our 1.1 release. In releases since then, we’ve continuously added to the feature set and in 1.7 we’ve introduced the most significant improvement to date. In 1.7, we’ve refined the capability around these themes:
Machine learning: We’ve enhanced our autonomous learning to capture even more data including inter-container network flows, post deployment process activity, and system call behaviors. This learning begins automatically as soon as we see an image for the first time and continues until the learning plateaus; usually within an hour or so of cumulative runtime.
Visibility: In 1.7, everything we learn you can see. We introduce the concept of models which are autonomously created descriptions of everything we’ve learned about a given image, including process, file system, network, and system call behaviors. It’s all visible for every image and we automatically archive and garbage collect old models.
Simplicity: In previous releases, you had to create different rules per sensor. For example, if you had image foo and wanted to create specific settings for process, network, and system calls, you’d have to go to 3 different menus to do so. In 1.7, models are complemented by rules that consolidate all the sensors into a single object. Even more powerfully, most customers need just a handful of rules, because the default rule says to ‘enforce the model’, meaning we’ll automatically alert or block based on what we’ve learned about the image and show to you in the model.
In Twistlock 1.7, we’ve greatly simplified the process for creating and maintaining a list of repositories and images that are trusted and give you simple policies to alert on or block deployment of images outside this list. The Trusted Images list allows you to add images to trust based on the repository they’re stored in, their image name, or their image ID.
Twistlock monitors the origin of all images on each host it protects and compares this to the Trusted Images list. If an untrusted image is added, Twistlock can log and alert or even block the deployment.
Trusted Images works with repositories on any registry, anywhere including Artifactory, Docker Trusted Registry, and services like AWS ECR and Google Container Registry. Twistlock automatically manages image points of origin and digests to enables you to enforce trust without any complex external dependencies.
Twistlock deployment templates
In 1.7, we’ve introduced support for deploying Defenders across Kubernetes clusters using Daemon Sets. Using a Daemon Set makes deployment very simple and automatic, regardless of how large your cluster is or how frequently you add nodes to it. With Daemon Sets, rather than installing Twistlock on each node individually, Twistlock generates a configuration file that you load into your Kubernetes Master and Kubernetes automatically ensures that every node in the cluster is running a Defender and that as new nodes are added, Defenders are installed on them as well. The net result is that you can ensure that every node in your environment is protected, without having to perform any manual installation steps.
Daemon Set deployment can be added to an existing Twistlock environment (once upgraded to 1.7) or used in a brand new deployment. If starting from scratch, the high level process looks like this:
- Deploy X number of K8S nodes to support your workload
- Connect to the Twistlock Console and get the Daemon Set setup script
- Run the script to automatically upload the Daemon Set config file to your K8S Master and to automate Defender installation across all nodes
Daemon Sets can be used to automate deployments on any up to date Kubernetes deployment, including OpenShift and Google Container Engine.
Granular vulnerability management rules
Twistlock has always provided customers with the ability to block images with vulnerabilities from being deployed. For example, you might create a rule with like ‘prevent images with Java vulnerabilities from being deployed on hosts called production-*’.
Beginning in 1.7, Twistlock provides more granularity in what vulnerabilities will trigger blocking actions by allowing you to specify the severity level of the vulnerabilities that trigger the rule. From the above example, this means that you could configure the rule to not block deployments on just any Java vulnerability but instead only on those vulnerabilities of a medium or higher severity.
Additionally, Twistlock now also allows you to block images that include specific CVEs. For example, if you deem that CVE-2016-1238 is particularly dangerous in your own environment, you can create a rule that will block deployment of images with that specific CVE while not impacting other images that don’t include it.
Finally, Twistlock now allows you to whitelist CVEs on a per rule basis (previously this was a global whitelist). For example, you may determine that a particular CVE isn’t relevant to your web containers because you mitigated the vulnerability in another way. Twistlock now enables you to create a rule like ‘ignore CVE-2016-1238 on containers named web-*’.
Vulnerability management for binary components
Typically, software in images is added through a package manager, such as apt, yum, or npm. Twistlock has a diverse set of upstream vulnerability data sources covering many different package managers across operating systems, including coverage for Node, Python, Java, and Ruby components. In these cases, Twistlock typically uses the package manager’s metadata to discover the installed components and versions and compares this data to the realtime CVE data feed provided via the intelligence stream. However, sometimes you may install software into images not using a package manager, such by just having a line in a Dockerfile to ADD the binary to the image or building the it via a configure, make, install approach. In these cases, there is no package manager data associated with the application.
In 1.7 and beyond, Twistlock uses a variety of advanced analysis techniques to detect metadata about software not installed via packages managers. This analysis then feeds our existing vulnerability detection and blocking mechanisms, continuing to give you a single view of all the vulnerabilities within a given image, regardless of whether they’re from the distribution layer, an app package manager, or added independently.
In Windows Server 2016, Microsoft introduced support for Docker on Windows. In 1.7, we’ve added support for vulnerability management for Windows images.\
Twistlock can integrate protection of Windows and Linux hosts seamlessly into the same environment. Specifically, a single Twistlock Console can protect both Windows and Linux Docker hosts. Twistlock’s Intelligence Stream has been updated to include vulnerability data from Microsoft, so as new CVEs are discovered in your Windows images, Twistlock will detect and alert on these findings, the same way it does on Linux.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Beyond App Security: Securing Applications No Matter Where They LiveRead the Blog
Surveying the Container Orchestration LandscapeRead the Blog
Building the Right Toolbox for a Successful DevSecOps CareerRead the Blog
BOD 19-02: DHS Vulnerability Remediation RequirementsRead the Blog
How Cloud Native Security is Adapting to New Hybrid Reality for EnterprisesRead the Blog