![image]( "image")
Microsoft Azure has a number of security partners and these partners help us help you deploy more secure solutions in Microsoft Azure. We greatly appreciate our partners work and encourage you to seek out the wide range of partner security solutions available in the Azure Marketplace. We also like to share a diversity of voices on this blog and are always happy to host guest bloggers.
A very hot topic these days is containerization. Containers allow you to containerize applications in a way similar to how we’ve containerized operating systems (via OS virtualization technology such as VMware and Microsoft Windows Server Hyper-V). There are a lot of reasons why you want to consider deploying containerized applications. For a great review of containers, how they work and how you can use them in Microsoft Azure, make sure to check out Mark Russinovich’s presentation on containers.
Of course, we here on the Azure Security and Compliance Team blog are also interested in containers, but we want to make sure when you deploy containerized applications that you do it in a secure fashion. There are some unique security considerations for containerized applications and you’ll want to be aware of them before you deploy in production.
To this end, I’d like to introduce one of our Azure Partners, Twistlock. In this article John Morello, CTO of Twistlock, will share with you their insights into container security. I think you’ll learn a thing or two!
=========================
With more than 50 years of Microsoft experience at Twistlock, we were naturally excited to see the Azure Container Service (ACS) being launched recently. ACS provides a simple way to manage and scale containerized apps using leading open source frameworks like DC/OS and Swarm. Because it’s built on the same open source technologies already available, Twistlock is able to protect workloads on Azure Container Service just as effectively as if you’re running them in your own datacenter, in another cloud provider, or even just on Azure VMs directly.
At Twistlock, we believe that with the right tools, containers can improve your security relative to running the same apps in a more traditional architecture. This is because of 3 essential characteristics of containers:
- Containers are immutable – you don’t service a deployed container when you want to update your app, you destroy it and create a new one
- Containers are minimal – they do one thing well and have just the bits they need to do it
- Containers are declarative – a container is built from an image, an image is composed of layers, and layers are described in a Dockerfile
For a security company like us, this means we can apply lots of advanced intelligence to these images throughout the development lifecycle. This helps us understand what they’re intended to do at runtime. Then, throughout the entire time a container is running, we compare what it’s actually doing to this reference model. When we see a variance, it can be an indicator of compromise (IoC) and we provide a policy framework so you can decide how to handle it (maybe you just want to alert in your test environment, but block in your PCI environment).
For example, if you have an image that’s supposed to run the Apache webserver, we understand what specific processes (like httpd) it should run, what syscalls it should make, and even what other containers it should talk to (like a backend database for example). Once you’ve deployed that image into containers, Twistlock monitors them and looks for anomalies to this model.
For example, if your Apache container starts listening on a different port or making a strange syscall or running netcat, it’s probably not a good thing. We also supplement this reference model with real time threat data so we can also detect malware that may be written to a volume your container has mounted or if your container starts talking to a Tor entry node or command and control system.
Most critically, all these protections happen automatically based on our knowledge of the image. Rather than some human having to create a rules and modify them as image are updated, we can do this discovery and recalibration automatically, every time a new image is built. This allows you to scale out an allow-list model of app security in ways not previously practical.
Let’s take a quick look at Twistlock on Azure Container Service in action. First, notice the containers running in this ACS deployment:
![clip_image002]( "clip_image002")
The webapp and db containers are linked (green) and I have another, separate, container, running a Node.js app next to them (pink). This is a common deployment model that containers help enable; having many different apps sharing the same kernel is safe and easy with containers.
I deployed the 2 tiered web app using docker-compose. One of the cool things about Azure Container Service is that because it’s a packaged implementation of existing tools, all those tools continue to work as you’d expect. So, deploying a multi-container app on ACS is as simple as running docker-compose up -d, just as you would in any other environment. In this case, the YAML file would look something like this:
morello@swarm-master-5B00EF84-0:~$ cat demo/docker-compose.yml
web:
image: training/webapp
links:
– db
ports:
– 32769:5000
db:
image: training/postgres
environment:
PASSWORD: examplepass
As with any other deployment, Twistlock scans all of the images and understands their vulnerability and compliance state, in addition to the runtime profiling we’ve discussed so far:
![clip_image004]( "clip_image004")
Once we know what the images should do, we can then compare to what they’re actually doing. In this example, let’s pretend an attacker finds a flaw in the Node.js app and attempts to compromise it. The first layer of defense in depth we provide is the syscall sensor. Because we understand what system calls the Node app should make, we can detect anomalies outside that allow list. In this case, the attacker exposes a flaw in the app to navigate directories and Twistlock detects it automatically:
![clip_image006]( "clip_image006")
For the purposes of this demo, let’s assume you didn’t configure to block this and ignored the alert. Now assume the bad guy uses his access to try to download an exploit kit. He first runs netcat on the machine and then wget. The process sensor knows those aren’t valid executables based on what was in the origin image:
![clip_image008]( "clip_image008")
At the same time, network sensor detects the traffic to a malware distribution point:
![clip_image010]( "clip_image010")
And the file system sensor sees when it’s written:
![clip_image012]( "clip_image012")
Remember, all of this happened without anyone having to create any rules based on the app or image; all the protections were applied automatically based on what the origin image should do. Here’s where it gets really cool, though. Twistlock also understands linkages between containers, so we know when inter-container traffic is by-design and when it’s not.
For example, if our hacked Node.js app has no reason to talk to the PostgreSQL database that’s running in a different container on the same host, you want detect and prevent attempts to do so. Here’s the hacked Node app trying to connect to the database:
![clip_image014]( "clip_image014")
Here’s Twistlock immediately identifying the connection attempt from an unlinked container:
![clip_image016]( "clip_image016")
Again, all this happens without anyone having to create and manage any rules, it’s solely based on our knowledge of the images and how they should talk to each other.
Azure Container Service provides a great platform for running containers and we’re proud to have a solution that helps customers today. However, there’s even more to come. We’ve also been doing work with the Operations Management Suite team so our security alerts can be integrated into the OMS data warehouse and presented in the same familiar dashboards as other Operations Management Suite data. Of course, we’re also excited about Windows Containers and you might guess that a team of ex-softies is going to make sure they’re protected too.
Thanks for reading! If you’re running container and Twistlock looks interesting to you, please check us out at https://twistlock.com or @TwistlockTeam. In addition to a free evaluation of our Enterprise Edition product, we also offer a completely free Developer Edition that’s great for individuals and small teams.
John Morello, CTO, Twistlock
===================
I hope you enjoyed this blog post and learned something new about container security.
Please let us know if you have questions about the Azure Container Service or container security. Just enter a comment in the Comments section below and we’ll try to find the answers you need.
Containers are cool and secure containers are the best!
![image]( "image")
Thanks!
Tom
Tom Shinder
Program Manager, Azure Security
@tshinder | Facebook | LinkedIn | Email | Web | Bing me! | GOOG me!
![image]( "image")
Hello Azure Security community!
Internet of Things (IoT) represents a new frontier. In the next few years you can expect to see literally billions of new IoT devices being introduced all over the world.
