Twistlock has always had strong advanced networking control on runtime defense features, including monitoring of socket bindings, linkages, and egress destinations against the various IP reputation list feeds that we have.
In Twistlock 1.5, we’ve taken the networking features further by incorporating sophisticated learning and predictive modeling capabilities to help us detect compromises that may be difficult to detect at the container level. These advancements are particularly relevant in light of the networking changes in Docker 1.12 that we discussed in a recent post. In this post, we’ll talk a little more in detail about how Twistlock helps secure the new Docker container networks.
Recall that in ‘legacy’ Docker networking, you essentially had just a single way to connect containers outside of a given host, via the bridge network. In Docker 1.12, this changes dramatically, with far more advanced SDN like capabilities that make overlay networking across hosts simple and easy for everyone to use.
Additionally, the legacy network model had a concept of ‘linking’, which provided a straightforward way to declare the networking relationship between containers. For example, you might link a front end web server container like NGINX with a backend database container like MongoDB. In Docker 1.12, user defined networks replaces container linking.
In Twistlock 1.5, we’ve implemented a machine learning model to discover, observe, and correlate network traffic automatically, WITHOUT requiring any user actions. We call this Advanced Networking control feature. This approach not only helps to increase detection accuracy, it also works great with user defined overlay networks.
Twistlock’s new advanced networking feature builds on our core philosophy: leveraging the most fundamental characteristics of containers – their minimal, declarative, and immutable nature – to automate the creation and maintenance of security models. Every time you build or pull an image, Twistlock begins examining it not just for malware, vulnerabilities, and compliance posture, but also to start building the predictive model for what it should be doing at runtime. To that end, we added a couple of major enhancements In 1.5. They are:
- Support for Docker user-defined networks: Twistlock now has the ability to discover inter-container communication patterns automatically across Docker user-defined networks. We then use these patterns for runtime anomaly detection. It is important to note that this process occurs with no human interaction required. As you define your new networks, Twistlock will automatically employ machine learning to build a predictive runtime model for your applications across the network. The model includes process, syscall, networking, and storage behavior aspects for the application. You simply deploy your app as you normally would, across whichever networks you want to connect to. We automate the learning and alerting / blocking from there.
- Advanced and targeted intelligence on apps within containers: In Twistlock 1.5, we enriched the runtime protection feature with app-specific intelligence that is not exposed at the container level. The app-specific insight can be derived from the application’s configuration as well as intelligent behavior modeling. For example, at the container level, we knew which ports were active and could detect whether a new, unpublished port, started listening to incoming connections. This helps to detect scenarios such as an attacker creating a new listener on a target to exfiltrate data from an environment. However, at this level, you might miss scenarios where another app starts listening on the same port. That’s where our new capability comes into play.
For example, if we see an image with an entrypoint of httpd we know that it’s Apache, we then find the config file for Apache and parse it for information like which ports are listening. This allows us to precisely correlate image -> app -> app network config, so that we can detect scenarios where an attacker has subverted the app and is using it to egress data or where the attacker has a malicious tool squatting on the valid listener. Let’s take a look at how this works.
First, I’m going to launch the official Apache image on Hub (note that for demo purposes, I’m starting a shell as the entrypoint, but the flow would be identical if we just ran with the default httpd entrypoint):
You can see Apache listening on 80 as you’d normally expect:
And we can connect to it from outside the container:
As soon as the new container starts, you can see Twistlock automatically discovers it and begins to profile it. Again, recall that all this occurs with no human interaction required. No one has to set up rules or change the way their image is built or deployed. This is what we see when tailing /var/lib/twistlock/log/defender.log:
Because all is normal at this point, you can note that Twistlock doesn’t have any alerts (see below):
Now, let’s assume an attacker somehow subverts the application within the container and attempts to exfiltrate data. For demo purposes, let’s further assume that our syscall, storage, and process sensors somehow do not detect the successful subversion. The attacker at this point may try to create a new listener for Apache that he’ll configure with settings that enable him to shovel data out. So he’s going to modify httpd.conf to listen not just on 80 but also on 81:
Notice that even though these changes are completely invisible if you’re just looking at container-level data, which you’d see via docker inspect, Twistlock would detect this anomaly because we are processing application specific information.
Using Apache to exfiltrate data is certainly far less common than a tool like netcat. So, what happens if the attacker kills Apache and puts netcat on the same port? Again, if you’re only looking at container-level intelligence, you won’t see that the app listening on that port is not the original app.
Because Twistlock knows the configuration of the app and the container, we can determine that, while the container hasn’t changed the port on which it is listening, the app running there is malicious:
This is just one small example of how containerizing an app can actually make it more secure. Containerization allows a tool like Twistlock to be able to automatically understand how the app should behave, through a combination of static analysis, observed launch time meta data, and applied machine learning to build sound predictive models. Twistlock uses this predictive model to identify behavior deviation and anomalies.
Containerization made it possible to automate this entire process of analysis, model building, and anomaly detection. Twistlock leverages that to scale the creation and maintenance of these protection profiles – every time you do a Docker pull or build, we create a profile. With our CI integration, we begin this modeling literally as soon as your developers start the build job. This level of automation is critical to protecting sophisticated DevOps-driven environments where manual tools simply can’t keep up with the rate of change.
We have more great innovations coming as part of our near term product roadmap. Stay tuned for more updates to come!
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