Announcing Twistlock 2.5
We just signed off on Twistlock 2.5, the 14th time we’ve shipped a major release of Twistlock over the past 3 years. A few other fun facts from GitHub: we’ve worked on more than 9300 issues, pushed more than 5200 commits, built Twistlock more than 820 times, and shipped 340 customer requested features to a couple hundred customers during that time!
In addition to the major new features below, this release includes dozens of other smaller improvements including:
- Enhancements to CNNF to expand compatibility with existing firewalls, NATs, and VPNs
- Expanded runtime defense capabilities on CoreOS
- Backup and restore integrated into the Console UI
- Additional enhancements for running in a pure runc / CRI stack
- More cloud provider IAM integrations for secrets management and authentication with Azure Key Vault, AWS Secrets Manager, AWS Parameter Store, and Azure Active Directory
— the Twistlock R&D and product teams
Herzliya and Baton Rouge
Cloud Native Forensics
Forensics and incident response changes significantly with containers. Some of these changes are obvious – the technology stack is different, the entities are more ephemeral, and the storage centric approach historically used may not be practical when it’s dynamically provisioned at a cloud provider. However, containers provide an opportunity to rethink forensics, to make it more proactive, simpler, and efficient than ever possible with traditional systems.
In Twistlock 2.5, we introduce the first cloud native forensics platform, an inherently proactive system for efficiently collecting forensic data before an incident occurs, coupling it with runtime defense and incident identification, and intelligently storing and sharing this data for analysis automatically. On each host that Twistlock protects, Defender maintains a first-in-first-out spool of process and network activity. This spool uses modern kernel interfaces to collect data at scale with nearly no additional performance overhead (Defender continues to typically utilize 1-2% CPU even on heavily loaded nodes). It maintains this spool locally so there’s no ongoing network overhead, and it automatically sends this data from the node to your Console when an incident is detected, integrating it directly into Incident Explorer.
Because this data is historical and pre-dates the incident, you have much greater visibility into the state of the container prior to compromise than traditional approaches have enabled. For example, you can see every process invocation and every binary creation that occurs, both normal and (if you’re not already preventing them with Twistlock) anomalous that leads up to the incident. Because this data is stored outside the container, it’s safe from tampering by the attacker. Because this data is stored on the same node, it has no network impact, even in very large and busy deployments. The end result is a more comprehensive, autonomous, and actionable approach to IR, with less performance burden and directly integrated with your runtime defense tooling.
AWS Fargate Runtime Defense
Since Amazon announced Fargate late last year, we’ve seen many of our customers adopting it as a way to simplify operations by spending less time managing infrastructure. Fargate’s promise is that you just need to request capacity to run your app and the EC2 instances are deployed and managed automatically. To deliver on this promise, Fargate prevents running containers with heightened privilege, making existing approaches to container runtime defense impractical. Instead of running as a peer “sidecar” container to your app containers, on Fargate protection must be delivered from within your app containers.
Some other solutions in the market provide this protection by requiring developers to manually embed their agent within every image you want to protect. While technically possible, this approach has some serious downsides: it requires you to change every Dockerfile in every image and tightly intertwine your security tool within them, making testing and debugging more difficult. Our approach still puts our Defender binary within each container but, critically, we do this automatically at the task definition level, instead of requiring you to manually change each image. This means that you can quickly deploy and enforce security policy using the exact same images you already use today, that your dev teams can test and debug them the same way, and that security policy is defined in the Twistlock Console rather than being hand coded into standalone config files within each image.
Because the entire process of embedding protection happens at the task definition layer, it also makes it much easier to integrate into CI/CD flows. Task definitions can be protected via the Twistlock API so the same jobs you use to run Fargate tasks can integrate security by just adding a single step to the existing flow. And that security is both powerful and simple – by default, Twistlock only allows binaries from the original image to execute, preventing attackers from running anything anomalous without needing to manually define any rules.
Radar is the visual canvas we use for showing your namespaces, pods, and containers in a live “Visio” that overlays connectivity, vulnerability, and threat data. We shipped the original version of radar all the way back in Twistlock 1.6, nearly 2 years ago. Since then, we’ve continued to refine and add to it and that work continues in this release. In Twistlock 2.5, radar adds additional awareness for namespaces with a default zoomed out view that allows you to see them all simultaneously, with shading to indicate which have experienced incidents, the relative severity level of vulnerabilities, and the connections between entities, both inter and intra namespace.
We’ve also enhanced the overlay data to allow you to see full vulnerability, compliance, and runtime data directly from the radar canvas. We continue to add features to our tabular views of this data and always will, but in 2.5 many users can work with their environments purely from the visual canvas, making it easier to conceptualize the architecture and connectivity of large environments, identify risks, and zoom in on incidents that require response.
Serverless Runtime Defense
We recently published a blog previewing our serverless capabilities and Twistlock 2.5 makes them generally available. We’ve seen many customers adopt serverless technologies like AWS Lambda as part of their cloud native stack. Serverless can be a great solution for simple app scenarios that do a single task and don’t need to persist state internally. Much as with Fargate, a fundamental premise of serverless providers is that users have very limited access to the underlying OS and no ability to run code with heightened privilege.
A reasonable question I’m often asked is why runtime defense is necessary given these constraints. The answer is that attackers are going to target the weakest layer in the stack, which is almost always your app, and try to extract whatever is most valuable by abusing it, which is whatever data it processes and stores. So, while a compromised individual function may not be able to directly compromise the host it runs on or other functions it runs next to, the attacker will still have access to whatever S3 buckets it interacts with, to manipulate any other functions or APIs it calls, and to intercept any data it processes. So, while the scope of the threat may be somewhat different, the impact of it can be just as significant.
We take the same philosophical approach to how we protect functions as we do Fargate: developers should not need to change anything in the code they produce, protection should be easy to integrate into CI/CD processes, and protection should be automatic by default. Developers simply build their functions as they already do, without loading any Twistlock libraries, adding any files, or changing any manifests. They have clean separation between what they produce and what we protect so testing and debugging is easy.
Policy is defined centrally within the Twistlock Console. When a function is ready to be protected, Twistlock has a simple API and tool to automatically add the Defender binary to the function and uses a default policy to ensure that only binaries within the original, genuine, function are allowed to run. If an attacker compromises code within a function, they’re unable to add their tools or launch a shell, providing a strong layer of autonomous prevention. Logs go both to your cloud provider’s native logging system and to the Twistlock Console.
Compliance has been a core part of the Twistlock platform since Twistlock 1.1 and we’ve continued to add to our compliance capabilities ever since. In Twistlock 2.5, we’re adding two major areas of functionality: custom checks and detailed results.
We’ve long supported OpenSCAP in Twistlock as a mechanism for defining custom checks beyond the >250 checks we ship in the product. We continue to support OpenSCAP and XCCDF based checks but for many customers these frameworks seem large and complex when all they really need is to check a few simple things. In 2.5, we’re adding a new feature that makes it easy to just run your own Bash scripts to do so. Depending on whether that script exits with a 0 or a 1, the check either passes or fails and you can define your own severity level for the check so it fits right in with the rest of the policy and rule logic we have for other compliance checks.
Many of our enterprise customers rely on Twistlock to both enforce and report on the compliance state of their cloud native environments. Historically, we’ve provided the results of what checks a given entity fails but some customers need to see both negative and affirmative results to prove compliance. In 2.5, we’ve added the ability to report on both passed and failed results and supplemented each finding with more detailed information. Specifically, we now show a few sentence description about the check, the raw results of the check (where applicable), and, for checks aligned with CIS benchmarks, the specific CIS version and section it corresponds to.
- Twistlock Platform
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog
CVE-2018-1002105: Critical K8s VulnerabilityRead the Blog
Advanced runc Debugging for Fun and ProfitRead the Blog
Introducing Twistlock Support for AWS Lambda LayersRead the Blog
Cloud Native Security Intelligence: Integrating with AWS Security HubRead the Blog