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.
Your Firewall’s Role in Cloud-Native Security
We live in the cloud-native era. That means the firewall strategy that...
Compliance, Microservices and Your Application
Compliance in modern applications that leverage containers, serverless...
6 Tips for Secure Data Management for Containers
One of the main reasons why containers have become so popular is that ...
OpenShift Internal Registry: Populating Registry Scans with Twistlock
Twistlock uses the Docker v2 Registry catalog API call to inventory im...
Better Together: Protecting Docker Registries with Twistlock and JFrog Artifactory
In a containerized devops lifecycle, a registry such as JFrog Artifact...