With the release of Twistlock 2.2, a new feature was introduced that helps to automate and improve the security of container hosts. Runtime defense for container hosts is similar to the runtime defense that Twistlock uses to secure containers, but with a few differences. Twistlock uses machine learning to automatically create a whitelist security model for hosts just like it does for containers. However, one obvious difference between hosts and containers is that containers are immutable while hosts are not. Due to this major difference, the way that Twistlock generates the security model is a little different for hosts.
Whereas the security model for containers is generated from the image, the model for hosts is generated from the processes on the host. Twistlock monitors file system interaction, processes (forks), and network traffic on the host (just like it does for containers). When the defender is creating the model, it will classify the processes as either a system service or an interactive process.
The behavior of an interactive process (such as sshd, display managers, etc.) are almost impossible to model since you would have to know the intent of the user. Twistlock does maintain logs of interactive processes, but does not try and model their behavior.
Fig. 1 – Example of interactive service log
System services, on the other hand, are very consistent and tend to have very patterned behavior which makes them ideal for behavioral modelling. The models that are created are per-process and per-host in order to maintain the greatest level of flexibility and accuracy.
Fig. 2 – Example of system service runtime model
Runtime defense for container hosts is automatically turned on by default, so there is no setup steps required by the user. The user is only responsible for creating and maintaining the rules that decide whether to alert or block suspicious behavior on the container hosts.
Fig. 3 – Example of create rule dialog for runtime defense for container hosts
This new feature adds to our existing container hosts feature set. Our commitment to protecting your entire container stack is realized by features like this.
Subscribe to our blog for cloud native cybersecurity updates, or get in touch for a demo.
- Find out how Twistlock uses its Runtime Defense to negate a Linux malware.
- Read our Ultimate Guide to Container Security to better understand the container environment!
- Within our latest Twistlock 2.2 update, we have created a new runtime defense feature, as well as a Cloud Native Network Firewall. Read about it now!
- Read more about Twistlock’s Runtime Defense.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
What Service Meshes Mean for Enterprise Security
Service meshes: Heard of them? By now, you may have. Service meshes ar...
The Business Value of Cloud Native Cybersecurity
“Software is eating the world,” Marc Andreessen wrote in 2011. Fiv...
How To Operationalize DevSecOps Practices
DevSecOps is not as much about the tools as it is about the people and...
Enhanced Visibility: Container Vulnerability Management from Build to Runtime
Earlier this year, I was at a large industry event and ended up speaki...
How Serverless Changes the Security Paradigm
Serverless architectures are quickly becoming a major technology withi...