Our website uses cookies

Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing Infosecurity Magazine, you agree to our use of cookies.

Okay, I understand Learn more

Enterprises Need to Stop Playing Catch-Me-If-You-Can With Their Containers

One of Leonardo DiCaprio’s finest performances is as the teenage con man Frank Abagnale Jr. in Steven Spielberg’s biographical crime film Catch Me If You Can. Frank is able to pass himself off as a doctor without ever having attended medical school, as a lawyer without having a law degree and as a pilot without attending flight school, in order to cash $2.5 million in fraudulent checks. 
 
Frank fools everyone by exploiting two simple premises. Firstly, unless alerted, most people will take what they see at face value. Secondly, exploiting a trusted role helps a conman misdirect his victims’ attention. These premises are also common techniques in the IT security world, where they are now being used to exploit vulnerabilities in Docker containers. 
 
There’s no doubt that enterprises are excited about the ability of DevOps to speed up their software development and to lower costs, but this enthusiasm sometimes blinds them to risk. Many enterprises, for example, aren’t even aware that they have deployed containers and orchestrated containerization.

It’s not surprising that they only recognize they have an issue when it’s too late and they then become engaged in a desperate game of ‘catch me if you can’.
 
The first challenge is for enterprises to identify when, where and how containerized applications are created and deployed within the business. Since they may have hundreds, if not thousands, of containers running, it can be extremely challenging to monitor and maintain visibility over what’s happening in each. What makes the situation even worse is that containers frequently do a Frank Abagnale disappearing act right in front of your eyes.

New containers are continually spinning up and existing containers are being shut down. By design, all the data inside a container disappears forever when the container shuts down. 
 
Even if the container no longer exists, if there’s a vulnerability that was previously exploited, there’s still a high probability that the threat remains.  
 
This points to another challenge facing DevOps and security teams. Software is not being kept up-to-date. Even if enterprises have policies and governance processes in place to identify vulnerabilities, staff still need to follow these processes, and organizations also need to ensure that a robust process has been deployed to add governance into containers.

Now you see me
Let’s consider one example of how containers can expose vulnerabilities. Developers usually take a Docker base image to build their application. The image becomes a ‘memory’ or snap-shot of the container, which the developer keeps offline, adding their applications on top. If the developers are using an eight-month-old image that has vulnerabilities that haven’t been patched, then that is a serious problem.

Although developers can deploy millions of containers incredibly quickly and change a whole environment with just a few lines of script, unfortunately most of those changes or the initial base image itself turn out to have vulnerabilities in them. As a result, any vulnerability in the container can give old vulnerabilities a new lease on life.

To discover how widespread this problem is, earlier this year [2018] Tenable analyzed the top 6,000 images on the Docker store for vulnerabilities. It discovered that while, on average, the vulnerability count in the official Docker images was 16, the average in community images was 40. 
 
Not only were there more vulnerabilities in the community images, but the risk profile was far higher. In the official images, 75% of the risks were identified as high, but in the community Docker images, 34% were found to be critical.
 
Many of the vulnerabilities discovered were both critical and old, meaning that exploit kits are readily available. Fifty-nine, for example, had the Shellshock flaw, while 359 were still affected by Heartbleed, even though it was discovered and fixed 4 years ago. 

Caught in the act
If you’re using containers and want to remain one step ahead of the likes of Frank Abagnale of this world, it’s essential that your security teams have easy and comprehensive visibility into both container image inventory and security.

By introducing security earlier into the development lifecycle and identifying vulnerable images as they are being created, DevOps can reap the benefits from agile development without exposing the business.

If you don’t have a container protection strategy in place then those old containers could be deployed within your environment and increase your cyber exposure, expanding how vulnerable you are.

What’s Hot on Infosecurity Magazine?