This past week we shipped Twistlock 1.5, which enhances runtime security and is now available to all our customers.
New Container Security & Scanning features of Twistlock 1.5
In this version, we have some exciting new features. I describe some of the new features in this post. Specifically, I want to focus on the following list.
- Advanced network protection
- Support for custom syscall protection rules
- Expanded admin roles
- Standalone scanner
- Support for alert profiles
Advanced app-specific network defense
In 1.5, we incorporated an exciting new feature – app-specific network defense. This feature allows Twistlock to target specific network protection rules for a given application. For example, when Twistlock detects that an image intended to run Apache, not only can we process Dockerfile statically to derive runtime information, we also automatically process additional, more in-depth information such as app-specific config files to learn specific behavior that is mapped to this application. This information is then used in creating protection rules in runtime security.
We provide this protection by combining our knowledge derived from image analysis with the runtime behavior analysis when the image is actually deployed. As always, we use Twistlock Intelligence Stream to deliver general and app-specific protection rules. This analysis and rule creation occurs automatically and requires no administrator interaction. When a container is found to be in violation of one of these rules, Twistlock will identify the runtime anomaly and either alert or block it, depending on the rules defined. This is just another example of how Twistlock is innovating on providing automatic protection for our customers throughout the container lifecycle.
Why is this important? We have learned that app-specific rules are a great augmentation to general rules. In general, the more specific you can get to with regards to a particular application, the more tailored your protection is going to be. We are excited to bring this innovation to our customers – especially considering this is done completely automatically!
Configurable syscall runtime protection
Twistlock has provided automated protection since our 1.2 release. In 1.5, we’ve added additional configurability to this function, allowing customers to create custom rules to explicitly allow or block certain syscalls. This feature gives flexibility and will override the automated protection rules if the two conflict. Otherwise, this feature is additive to the automated syscall protection that is already part of our product.
For example, if you add an entry to the ‘always allowed’ list, Twistlock will never alert or block on that syscall, but will continue to do so for any other automatically detected syscall anomaly.
Why is this important? In certain environments, it makes a lot of sense to create exceptions to automated rules. This capability allows some of the edge cases of rules to function correctly without causing any false negatives or false positives.
Expanded admin roles
In 1.5, we added three new admin roles for the Twistlock product: Auditor, Defender Manager, and Operator. These new roles provide additional flexibility and granularity of access for a given user or a group to manage Twistlock.
- The Auditor role provides read-only access to all Twistlock settings and logs, but has no write permission to modify settings or logs.
- The Defender Manager role is the admin specifically for managing Twistlock Defenders.
- The Operator role provides the ability to update and change all settings within Twistlock, except those related to role assignment and user management.
These new roles are designed to help customers better delegate management responsibilities and meet their compliance requirements.
Why is this important?: Fine-grained admin delegation is important for enterprise environments, and this allows exactly that.
We’ve long provided native plugins for popular CI tools like Jenkins and TeamCity. These plugins allow you to integrate Twistlock vulnerability management directly into the build process so that your developers can see and fix problems before images ever get to a registry.
To support customers who have the need for specific CI tooling or to allow them to integrate vulnerability management into another workflow separate from CI, we released a standalone scanner function in 1.5.
Twistlock scanner is a standalone, statically compiled binary that can run on any Linux host. It can operate without any other Twistlock software present. It performs image scanning and makes the results available in an easily consumable JSON format. With this, you can ingest scanning results into any CI tools that you desire.
Twistlock scanner can be simply added to the host running these CI tools and called from a simple shell script to start analyzing images as they’re being built. The scanner also produces a full hierarchical bill of materials of the content of an image, including hashes of all files, even those in archives.
Why is this important: While we think it’s important to integrate vulnerability scanning with runtime enforcement, which is what we do within our container security enterprise platform. We do realize that some organizations may have needs to embed a scanning capability in other workflows. This allows them to do that while still leveraging Twistlock’s enterprise platform to do end to end protection.
In 1.5, we added functionality for customers to create specific alert profiles to trigger on specific rules. This allows flexible alerting, which a customer can use to set up granular rules to apply specific actions to different events. For example, you may want Twistlock to send an email to the networking team when a network runtime violation occurs, but to email the security team to a failed access control audit event. Alert profiles allow you to centrally configure which recipient(s) corresponding to which alert scenario, which is a powerful incident response function.
Why is this important: Many of our customers have asked for this. In an enterprise DevOps environment, there are many different roles that may be relevant for the same environment, but they don’t have need-to-know for everything. So this new feature allows the right people to know the right events at the right time.
For existing users, installing Twistlock 1.5 is a simple upgrade, as long as you have a valid license key.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog