Twistlock Adds Forensics to Container Security Platform
Twistlock today announced it is adding a forensics capability to its container security platform to provide cybersecurity teams with more visibility into events that occurred prior to a cybersecurity issue being discovered.
Version 2.5 of the Twistlock container platform marks the first time organizations can collect forensic data using a Defender utility prior to when an incident occurs, says CTO John Morello. Each instance of Defender runs locally and maintains a first-in, first-out spool of process and network activity with a minimal amount of overhead. Defender then automatically sends data concerning every process invocation and every binary creation that occurred to the Twistlock console once an incident is detected—a capability that he says enables cybersecurity teams to travel back in time by providing them with a real-time recording of every event affecting a container.
That data is then coupled with the container runtime defense and incident identification capabilities already provided by Twistlock, and can be stored in an open format to facilitate sharing that data with third-party analytics applications automatically, Morello adds.
At the same time, Twistlock is extending the reach and scope of its container security platform to include the Fargate runtime created by Amazon Web Services (AWS). Fargate provides a task manager that makes it possible to dynamically request additional compute capacity while running an application whenever necessary. Fargate, however, requires AWS to prevent containers with heightened privilege from running. To circumvent that issue, Twistlock is now making possible to run the Defender binary within each container at the task definition level, rather than running container security software in a so-called “sidecar fashion.” That eliminates the need to manually change each container image anytime there is a need to update a cybersecurity policy, Morello says.
Finally, Twistlock announced it is now delivering support for serverless computing frameworks that it previously announced along with a revamped Radar visualization module; extended compatibility with a range of existing firewalls, NATs and VPNs; support for CoreOS runtimes; and backup and recovery capabilities accessible via the Twistlock console.
Morello notes generally there exists a need to apply the same security framework to both containers and serverless computing frameworks that will be viewed as a natural extension of containers. Cybersecurity teams will want a common security console to protect two complementary approaches to building and deploying cloud-native applications, he says.
Most cybersecurity teams have yet to come to terms with the different operational model they will need to master to secure containers, he adds. Developers are part of the general shift of responsibility to the left for implementing container security policies that are defined by cybersecurity teams, also known as DevSecOps. Containers are ephemeral artifacts that often come and go in seconds, which requires cybersecurity teams to shift away from relying on IP addresses, for example, to implement security policies, says Morello.
There’s no doubt containers and serverless computing frameworks are about to transform cybersecurity utterly. The challenge now is figuring out how to get developers and cybersecurity teams on the same best practices page.
