Assembling A Container Security Program: Threats

After a somewhat lengthy hiatus - sorry about that - I will close out this series over the next couple of days.

In this post I want to go into some of the threat models for containers, and more specifically, Docker containers. Some of these are known threats and issues, some are purely lab exercises for proof of concept, while others are areas threat vectors attackers have yet to exploit – likely because there is so much low hanging fruit for them to go after elsewhere.

So what are the threats to container environments?

Build Environment

One area that needs protection is the build environment. It’s not first item on most peoples list for container security, but it’s first on mine, because it’s the easiest place to insert malicious code. Developers tend to loathe security in Dev as it slows them down. It’s for this reason there is an entire industry dedicated to test data management and masked data; because developers are likely to do an end around on security if it slows down the build and testing process.

Specifically what kinds of threats are we talking about? Things like malicious or moronic source code changes. Malicious or moronic alterations to automated build controller. Configuration scripts with errors or with credential information sitting around. The addition of insecure libraries or back-revved/insecure versions of existing code. We want to know if the runtime code has been scanned for vulnerabilities. And we worry that a failure to audit all of the above and catch potential errors.

Container Security

What the hell is in the container? What does it do? Is this even the correct version of the container? These are common questions that I hear a lot from operations folks. They have no idea. Nor do they know what permissions the container has or requires; all to often lazy developers run everything as root, which tends to break operational security models, and opens up the container engine and underlying OS to different attacks. And security folks are unaware of what – if any – hardening of the container has been performed. Essentially, have the contents of the container been patched, vetted, hardened and registered prior to deployment.

Runtime Security

So what are the threats we are worried about? We are worried that a container will try to attack or infect another container. We are worried that a container may quietly try to exfiltrate data, or just exhibit any other type of odd behavior. We are worried that containers have been running a long period of time, and therefore not been rotated to newly patched versions. We are worried that the network has been properly configured to limit the damage from a compromise. And we are worried about attackers probing containers, looking for vulnerabilities.

Platform Security

Finally, the underlying platform security is a consideration. We are worried that a container will attack the underlying host OS or the container engine. If successful, it’s pretty much game over for that cluster of containers, and you’ve possibly given malicious code the resources it needs to pivot and attack other systems.

If you’ve been in the security industry long enough, you see several patterns repeat over and over. One is how each hot new tech becomes all the rage, finds its way into your data center, and before you have a chance to fully understand how it works, someone’s labeled it as a ‘business critical’. That’s about the time that security and operations teams get the mandate to get said hot new technology secure And it’s a natural progression as every software platform needs to focus on getting the minimum usability, scalability and performance features into the product before competitors come and eat their lunch. After a certain threshold of customer adoption is reached – namely enterprises really start using it – customers start asking “Hey, how do we secure this thing?”

The good news Docker has reached that point in the evolutionary cycle where security is important to their customers, and by proxy, has become important to them as well. They have now implemented a full set of IAM capabilities – meaning identity management, authentication, authorization and (usually) single sign-on or Federation – plus encrypted communications to secure data in transit. For the rest of the features that enterprises expect – configuration analysis, software assessment, monitoring, logging, encryption for data at rest, key management, dev environment security – you’re looking at a mixture of Docker and 3rd party solution providers fill in the gaps. We are also seeing cloud providers like Azure and AWS map their core security services over the container environment, providing different security models from what you may employ on-premise. This is an interesting time for container security in general – and a bit confusing – as you have a couple different options for any given threat. Now we will delve into how to address these threats at each stage of the pipeline. Next up, build environment security.

- Adrian Lane (0) Comments Subscribe to our daily email digest

from Assembling A Container Security Program: Threats