As cloud infrastructures become widely adopted across many organizations, some are also moving their software projects to the cloud — specifically containerized environments. While this move brings agility and scale with it, a false assumption can also arise: “My applications are inside containers, so they are secure.” In reality, however, it’s often the opposite.

Putting applications into containers does not make them secure. For example, legacy applications may include previously unknown vulnerabilities. Container images may have vulnerabilities that date back several years and can rely on older frameworks that have known vulnerabilities. Containerized applications can run with excessive permissions, and the cloud itself can be misconfigured and leak data.

In all cases, applications and images do not gain security benefits simply from being containerized. Vulnerabilities will still exist, but you may just not know about them. Furthermore, managing security in the cloud follows the same basic rules as managing on-premises environments.

What Are Containers?

Before diving deeper into the topic, let’s define the word “container.” Although containerization in the cloud is a concept that has been gaining momentum across all sectors, not everyone knows what containers are and how they fit into the larger concept of a cloud environment.

The best analogy for containers are those colorful shipping boxes you see on large ships. Each box contains a set of goods, however, since you did not develop or pack the goods, you cannot see them nor know which types of goods are inside each one. Each container is a separate box that does not interact with the other boxes, although they may all be going to the same destination.

Containers in the cloud are similar to those boxes, except they are virtual. Developers build applications and put them inside containers. They can build separate parts of an application into each container and have the different parts essentially “sealed,” even though they all run in the same cloud.

But while containers are there to provide isolation, the misconception that containers provide security for the applications inside them is a container security challenge within itself. It is tough to flip a misconception, especially when it involves taking additional steps in the container deployment and management process to integrate security.

Container Security Challenges Start With a Lack of Visibility

Challenges around secure containerization begin with a lack of visibility. Since IT organizations are typically the end receivers of containers — for example, applications were developed by a separate group, who, in turn, included software from other sources — it is tough for the company to know if applications were designed securely. How do you know if secure, up-to-date software was used? How do you know if the applications were tested to find and fix high-risk vulnerabilities that an attacker may exploit?

The simple answer is that unless security was integrated into the process and documented as part of the project, you likely don’t know. Without knowing who developed the applications and how, it is nearly impossible to understand their security posture.

To make matters worse, containers tend to be “deploy and forget” assets, which could mean that no one is monitoring them for suspicious activities, outdated applications, lack of tooling and other security components. This lack of visibility into their security posture means fewer eyes on security gaps. When assessing the security of containers, X-Force Red, IBM Security’s team of hackers, typically finds security deficiencies, such as misconfigurations, overly permissive access rights and insecure application logic, libraries, middleware and frameworks, to name a few.

Even With Basic Container Security Controls, Challenges Still Arise

Some organizations may be implementing basic container security processes, such as scanning the container environment to identify and fix vulnerabilities that could expose their contents to attackers. The limited number of organizations that do perform container scanning, however, face their own set of challenges. Each scan tends to uncover thousands of vulnerabilities, each with its own priority and risk profile, as well as remedial possibilities.

Buried in an already charged patching program, and often with limited manpower and time, security teams do not know which vulnerabilities pose the highest risk of a compromise, making it nearly impossible to know where to start with remediation. As teams manually try to prioritize the vulnerabilities that matter most, the window of opportunity for an attacker becomes larger. They may also waste resources by chasing down false positives and low-risk vulnerabilities, as the most dangerous ones continue exposing valuable assets or patching gets deferred until it’s too late.

Strengthening Container Security in 2020

If just one of those security vulnerabilities enables attackers to gain access to an organization’s container(s), attackers could also compromise the organization’s internal environment and gain access to all of their assets — those in the cloud and on-premises. So, how can companies strengthen their container security more effectively?

It starts with understanding the container misconception. Just because your applications are inside a container that does not mean they are secure. Companies should then assess their container environment, which includes identifying which kinds of applications are in the containers, how important they are to the business, and what kind of data resides on them or is accessible by them. Companies should also review their containers’ existing tools, processes, workflows and technical controls, so that they understand how, if at all, the applications inside are being protected and where gaps exist.

To do that, security teams could begin by performing a scan of their container environment. Scans, however, can typically uncover thousands of vulnerabilities, leaving security teams trying to manually piece together which ones pose the most risk and must be fixed first. That is why a real-world risk ranking capability is essential. Scanning and automated ranking must go hand in hand. After all, what is the point of identifying vulnerabilities if you do not know where to start fixing them?

A risk ranking system that is based on real-world weaponization of vulnerabilities, asset impact and exposure can be used to prioritize vulnerabilities so that the highest risk ones are at the top of the list for remediation. Automating this type of ranking using threat data makes the scan findings actionable so that remediation can begin immediately, and remediators only spend time and resources fixing the vulnerabilities that matter most. From there, steps to fix the vulnerabilities and prevent more in the future begin. That may mean making policy changes, monitoring container activity and analyzing suspicious events that are relevant to that environment.

Those additional steps may sound like a lot of work, but if your organization is scaling up delivery through containerization, then its cloud assets are part of the security program and must be handled as such. To avoid issues down the line, it is worth it to reduce your risk of a container breach.

Watch the webinar to learn more about container security