How to achieve security via whitelisting with Docker containers  

Twistlock has developed techniques that effectively provide whitelisting to Docker containers

This column is available in a weekly newsletter called IT Best Practices.  Click here to subscribe.  

Docker containers have become an important means for organizations to build and run applications in the cloud. There’s a lot of flexibility with containers, as they can be deployed on top of any bare-metal server, virtual machine, or platform-as-as-service (PaaS) environment. Developers have embraced Docker containers on public clouds because they don’t need help from an IT operations team to spin them up.

A software container is simply a thin package of an application and the libraries that support the application, making it easy to move a container from one operating system to another. This makes it possible for a developer to build an application and then take all the source code and supporting files and basically create something like a zip file so the container can be deployed just about anywhere. It contains everything the application needs to run, including code, runtime, system tools and system libraries.

There are several characteristics of containers that lend themselves nicely to intent-based security, which, in effect, is whitelisting. I recently interviewed Ben Bernstein, co-founder and CEO of the container security company Twistlock, to get his perspective on ways to protect container applications.

“People in security have been trying to reach the Holy Grail, where the best way to protect the workload is by doing whitelisting,” says Bernstein. Whitelisting is the practice of specifying an index of approved applications that are permitted to be present and active. Anything that isn’t on the “approved” list is simply not permitted to execute. “With whitelisting,” says Bernstein, “you know what is supposed to happen. If something deviates from that, you can assume it’s not good. The thing about whitelisting is that it’s very hard to do.”

Twistlock came up with a concept it calls “developer intent.” It’s based on three things that didn’t exist in the old world of application development. Essentially, containers are declarative, predictable and immutable. Let’s have a look at how those characteristics add up to intent-based security.

There is much more declarative information available with containers. Now a developer doesn’t just write code; he creates a small environment in which the code should run (i.e., a container). He knows exactly which processes should run in that environment. “The developer doesn’t create a security profile and say, ‘I just created a container and these are the processes that should run in it.’ But he does give that information implicitly,” says Bernstein.

Twistlock takes that information and, using heuristics, comes up with a list of known processes with the exact hash and exact information. “If someone breaks into the application and spins up a shell that should not be running there, we know that for a fact,” says Bernstein. “If he spins up a tool, we don’t need to figure out that tool was used in a Russian attack three months. We just know that this process, whatever it is, wasn’t part of the developer intent. And that is sort of a low hanging fruit example of how you can basically whitelist what is supposed to happen.”

The second piece that goes into the security formula is predictability. In the cloud era, each developer owns a smaller piece and there are no big monolithic milestones. These small pieces are easier to analyze. “In the container world, developers typically don’t write the entire stack themselves. They use layers, and in these layers they basically hint to you what is supposed to happen,” says Bernstein. “So if you see a stack, and in the stack you see Ubuntu, and on top of Ubuntu you see he put in a MySQL layer, these are basically layers that sit in a registry that each developer can pull in. Then you can assume that because it’s a microservice, that’s probably going to be a database because you recognize all these layers that came from the registry and you know exactly which puzzle pieces he has. You could look at the different layers that exist and create some kind of a dictionary between these layers and behaviors.”

Bernstein adds, “If you see MySQL, Ubuntu and a thin layer of configuration, you know that this shouldn’t ping your internal network. If it was SharePoint or something in the old world, there could be a lot of things that a certain VM could do, but in microservices it is much more predictable. Even if you don’t recognize all the layers that the developer used, just because of the fact that it is a very thin and minimalistic service, it is much easier to use machine learning in order to baseline what it is supposed to do. There is a lot more signal and a lot less noise in a microservice environment, and it is much easier to baseline.”

The last piece is that containers are immutable; that is, unchangeable. When a developer wants to change or update his application, it doesn’t happen in real time. Instead, he completely replaces the entire container with a new version. This provides a lot of power from a security standpoint because, if you see a change in the behavior of the application and it wasn’t a change that the developer pushed, it’s an issue. It’s either configuration drift or a real attack, both of which are bad.

These three attributes – declaration, predictability and immutability – create a whitelisting style of security that, along with blacklisting, provides strong protection for cloud applications.

“If you create a cloud workload today and you want to secure it using old world tools, there are three things you have to do,” says Bernstein. “You have to make sure that developers don’t put bad things into production. You have to make sure that no threats are able to get to the application, and you want to make sure if you did get infected by something, you are alerted and you understand there are anomalies. We believe those three things are part of one package and this is what Twistlock does today. We sit on the host, we make sure that only hygiene things come in, and whenever things come in we make sure that we understand them. We protect you from threats that might exist and we detect anomalies using the range of whitelisting techniques.”

Copyright © 2017 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022