Traditional runtime security tools typically require a human to manage and configure rules to protect apps, such as what processes should run, what components should talk to what other components, and what system calls are required. However, as your app landscape grows and your dev cycles shrink, this approach doesn’t scale and Docker app security is a must.
At Twistlock, our vision is to help customers use containers to improve the security of their applications. We think the fundamental characteristics of containers- their declarative and minimalistic nature and the immutable deployment model- enable a security company like ours to automate runtime protection in ways that just weren’t feasible in more traditional app architectures. That’s why we were excited to see Docker Universal Control Plane, an app centric way to deploy and operate containerized apps that helps customer embrace and scale these characteristics.
Twistlock is a long time contributor to Docker and we’ve built our runtime capabilities to leverage many of the great aspects of the platform. When you deploy an app to cluster UCP is managing, Twistlock automatically builds runtime defense profiles for that app, covering storage, networking, process, and system call activities. We use Docker APIs to understand what the app should be doing, then continuously monitor what it’s actually doing to detect anomalies. We complement this reference monitor with real time threat data that helps us identify risks like malicious files, processes, and network connections. Finally, we allow you to either alert on these variances or actively stop them and put their containers into a forensics ready state for further analysis.
Critically, though, this is all fully automated. Twistlock automatically profiles the app to understand how it’s built, what processes should run, what sockets it should listen on, and what inter-container communication should occur. We also provide syscall profiles, both automatically generated and complemented with research from Twistlock Labs and delivered from our cloud service. Devs don’t have to build new artifacts for their apps and security teams don’t have to manually create rules to protect them.
For example, let’s assume I have a simple blogging app composed of a WordPress front end and a MariaDB backend. I’ve described this app in a compose file that looks like this:
I deploy this file to Universal Control Plane (UCP), the integrated orchestration stack in Docker Datacenter, by simply running docker-compose up -d. Now I get all the great app centric management and scaling capabilities that UCP provides:
At the same time, Twistlock has automatically learned what the linkages between the components should be, built a map of the digests of all the processes that should run in each, and is monitoring the file system and network traffic for each.
The ‘allow list’ approach for app security is now as scalable as your apps themselves are. The developers didn’t have to build anything other than the compose file they normally would. The ops team doesn’t have to create a special deployment package. The security team doesn’t have to build and manage complex rules for each app. Instead, because you’ve embraced containers and you have a security tool built for them, you’re able to use the essential characteristics of containers to your security advantage.
Maybe this WordPress app is running next to another app that’s not as well secured, like this NodeJS app that UCP shows in it’s container view:
If that container gets compromised, Twistlock can detect the compromise and the attempts to further the intrusion. First, Twistlock can detect that an un-allowed syscall was made to the Node app that led to its compromise. In the real world, you might have Twistlock configured to automatically block this, but to illustrate defense in depth, let’s assume it’s successful:
Next, the attacker downloads his exploit kit. This is an example of Twistlock’s threat based protection in action, since the download is from an IP endpoint in our threat feed and the file is malicious, so it trips both the network and file system sensors.
The process sensors are also triggered when the attacker tries to use wget and netcat to download his kit. Because Twistlock has profiled the origin image used to launch the container, we know that these processes should not normally be running:
Finally, because the WordPress app was launched onto a UCP managed cluster via a compose file, not only does UCP know about its topology, but so does Twistlock. Specifically, we know exactly what inter-container communications should be allowed and can detect anomalies. In this case, as soon as the WordPress container sees traffic from an unlinked container, Twistlock detects it and alerts on the anomaly:
Docker Datacenter makes it easy to ship and run your apps in containers. Containers have fundamental characteristics that let a security company like Twistlock automate profiling of your apps in a way that’s both deeper and more efficient than traditional architectures and dev processes allow. By combining UCP and Twistlock, you can deploy and manage your apps faster, easier, and more securely than ever before.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Announcing Our Series C FundingRead the Blog
Real Time View of Your Cloud Native Applications: Radar v3Read the Blog
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog