Announcing Twistlock 2.1!
We just signed off on Twistlock 2.1, the 10th time we’ve shipped a major release of Twistlock. 2.1, which includes some great new features across all areas of the product, including a first of its kind container centric app firewall, vulnerability risk ranking that uses our knowledge of your unique environment to prioritize what to fix first, a brand new dashboard, and integrated secrets management based on our latest work in the Docker open source project.
Cloud Native App Firewall
In traditional Web App Firewalls, the WAF is separate from the app and requires a human being to relate the two together. For example, if you’re running WordPress on a VM at 192.168.2.100 and you want to filter traffic to it, your developer probably has to tell your security team to configure their WAF with what filter to use and where to send traffic. You might also have to configure and run some kind of load balancer to front end the traffic and then when you need to add another VM to handle the scale, everything might need to be reconfigured again.
In a cloud native scenario, where you’re deploying this app in containers and with an orchestrator, a lot of these assumptions become even more difficult to manage. Now, your app may not always have the same IP and it may be running in environments where you don’t fully control the routing topology or can’t easily add load balancer and application filters. Furthermore, each time you deploy a new app, you have to coordinate multiple groups of humans to make all these components work together properly.
Because we have a deep understanding of all your apps, are running on each of your container hosts, and can see all your app traffic, we can dramatically simplify this whole flow. In Twistlock 2.1, we’re introducing our Cloud Native App Firewall (CNAF) that combines our knowledge, placement, and visibility to be able to automatically protect your apps at scale with far less manual interaction and in a completely ‘software defined’ manner.
When you enable CNAF in the WordPress example from above, we automatically know all the places where you’re running WordPress, automatically re-route inbound traffic destined to those containers and pods through Defender, apply a highly optimized, application specific, layer 7 filter to it, sending only clean traffic to the actual container. Critically, this all happens without having to change anything in your images, containers, or architecture. We can dynamically learn where to apply these filters, transparently filter application traffic against common attack patterns like SQL injection and cross site scripting, transparently block requests from malicious endpoints, and ensure that only safe traffic reaches your app, all without having to configure external devices or ever enter an IP address.
Most container vulnerability management tools will find and show you a list of vulnerabilities in your images. We’ve always looked at vulnerability management more broadly and focused not just on telling what’s wrong, but also giving you the tools to prevent those problems in the first place, like with our ability to fail Jenkins builds and prevent containers from running based on vulnerability severity thresholds.
In 2.1, we’re taking this even further by not just showing you a list of vulnerabilities, but by giving you an actionable, stack ranked view of the most critical risks in your own specific environment based on your own unique deployments. Because we have visibility into how your containers are deployed, we can use this knowledge to show you the risks that are most important to you, so you can prioritize your work and identify and remediate the most critical problems more rapidly.
For example, imagine you have 2 images, both with 5 high severity vulnerabilities. One of them is the front end of a public facing web app and the other is a caching service that’s not exposed to the network. We know what images are running as root, what images are missing mandatory security profiles, what images have ports exposed, and which ones receive traffic from the internet. Instead of just showing you those 2 images in a list sitting next to each other, we’ll calculate risk scores for each based on the specific way you’ve deployed them, so you can prioritize and allocate resources accordingly.
We’ve also integrated a graphical interface for our vulnerability risk tree directly into Vulnerability Explorer, so for any given vulnerability, you can instantly see your exposure. Because we know what vulnerabilities impact what packages, what packages are in what images, what images are in what containers, and what hosts those containers are running on, with a single click you can instantly fan out the full scope of your exposure across all those objects.
Most of our customers are large enterprises that have many different teams working on many different apps that often share the same environments. For example, you may have a single Kubernetes cluster that you use to run a shopping app, a travel app, and an expenses app for your organization. Different teams within your organization may be responsible for each app; for example, your corporate controller team may run the travel and expenses app, while your marketing department runs the shopping app. While you’ve always been able to set filters within any view in Twistlock to show you only specific items, these filters weren’t persistent and weren’t centrally managed. In Twistlock 2.1, this all changes with Twistlock Collections.
Collections is a feature that enables you to centrally create and manage pre-defined filters for your environment that you can use in rules and views across the product. These filters work like the filters we’ve always had, as simple text regexes that are matched against images, containers, hosts, and labels. This allows Collections to be created for whatever arbitrary structures you’d like, such as by project, organizational hierarchy, geography, or some combination thereof. From our previous example, you may create a collection for marketing and another for controller. When a user is looking at any data in Twistlock, they can easily choose the appropriate collections from the multi-select box and then scope their view to only those results that match the filters. So, if you’re a developer for one of the controller apps, you could select the controller collection when looking at image vulnerabilities and only see those images you’re responsible for. This selection is sticky throughout your session, so as you navigate around the Console, you see what’s important to you.
Compliance Alerting and Enforcement in Jenkins
Twistlock has long supported the ability to alert on and enforce vulnerability thresholds during the CI process via our native Jenkins plugin. For example, you can create a rule in Twistlock like ‘fail the build if a medium or higher vulnerability is discovered’. Or you can simply warn the developers about the problems while showing them a detailed graphical summary of their vulnerabilities directly in the Jenkins UI.
In Twistlock 2.1, we’re expanding this CI integration to also cover image compliance. This means that you can now use Twistlock to check, alert on, and fail builds based on compliance posture, such as whether the image runs as root or if it has embedded private keys or secrets. This capability is all about the ‘shift left’ concept, helping you move both security and compliance further upstream in your development process.
Leading orchestration platforms like Docker Swarm and Kubernetes have native support for secret distribution. These platforms enable users to store secrets like private keys, passwords, and connection strings centrally and provide them on-demand to containers, rather than embedding these details into your images in the clear. For example, you can create a Docker Compose or Kubernetes deployment file that references a secret and provides it securely to the containers that you specify as they start.
One limitation of both of these platforms, though, is that these secrets must be stored within the orchestrator software itself. Many organizations have already standardized on enterprise secret management platforms like HashiCorp Vault or CyberArk Enterprise Password Vault not just for secrets related to their containers but for many other use cases around the enterprise. These products provide centralized secure storage and auditing so if you’re already using one, you likely want to extend it into your containerized environment rather than create another silo of secrets.
In Twistlock 2.1, we’re enabling exactly that scenario. Our new Secrets Manager allows you to integrate Twistlock with both HashiCorp and CyberArk and then to have Twistlock securely distribute the secrets from those stores into the containers you specify. Critically, Twistlock never stores the secrets outside of those systems and we integrate seamlessly with the access control and key rotation methods both already support. So, with 2.1, you can easily and safely link your existing secrets management platform with your containers and securely distribute secrets from them to your all your apps.
The really cool part of our approach, though, is that we’re not just doing this in Twistlock. We’ve been proud to contribute authorization and security features to the Docker and OpenShift projects and we’re doing that again with secrets management. Our implementation in Twistlock 2.1 builds on top of an open source backend we’re contributing to make Docker Swarm’s secret manager pluggable. This means that others can build their own providers for this plugin to allow for secrets to be securely retrieved from any conceivable secrets manager and securely injected into containers using the native capabilities in Docker Swarm. Our implementation in 2.1 uses this same framework to connect HashiCorp and CyberArk to both Swarm and Kubernetes and you can expect more info about it in the future as as this feature makes into mainline Docker.
Vulnerability Push Alerts
We’ve long supported ‘push’ alerting for events across Twistlock, in which you can centrally define alert profiles with set of email address and other channels have alert messages sent to those profiles when events occur within Twistlock. In 2.1, we’re extending this capability to provide rich HTML based email alerts for vulnerabilities detected across your environment. These alerts are configurable, so you can send alerts about specific images just to the team members responsible for those images. This enables you to create an automated process for your development teams to get push notifications about new vulnerabilities discovered in the apps they maintain, without having to manually run a scan or visit the Console.
Vulnerability alerts are also designed to make it easy to understand what new vulnerabilities impact your apps each time those reports are sent. We break out each alert to show the full set of packages and vulnerabilities associated with them, but also have a specific section just to show what vulnerabilities have been newly discovered since the last alert so you can easily identify what new risks you need to triage.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Baking Compliance in your CI/CD PipelineRead the Blog
Serverless Security Suggestions: Tips for Keeping Serverless Functions SecureRead the Blog
Why a Common Security Toolset is Essential for DevSecOpsRead the Blog
Putting the “Ops” in DevSecOps: Why It’s Hard and How to Do ItRead the Blog
Why the Point Solution Mindset for IT Security is DeadRead the Blog