5 Risks You Need to Remember When Securing Your Containers

Containers are on the rise. As reported by GlobalNewswire, Allied Market Research estimated that the application market would grow from its 2016 value of $698 million to $8.20 by 2025. With a compound annual growth rate of 31.8% between 2018 and 2025, this increase would largely reflect both the surge in popularity in application container technology along with a growing number of organizations’ migration to the cloud.

Not all is rosy with application containers, however. Indeed, Allied Market Research found that security risks held back the growth of the application container market to a certain extent. Such risks aren’t going anywhere anytime soon, either. As a result, organizations that are looking to incorporate containers into their environment need to be aware of these security risks.

This blog post will discuss five of those dangers in particular: enabling microservices, reliance on insecure base images, incomplete container visibility, unrestricted container communication and insecure container configurations.

Enable Microservices

CIO explains that containers are a type of technology that consist of an entire runtime environment including binaries, libraries and other components. By design, containers render differences in OS distributions irrelevant. They therefore make it easy for DevOps team members to allocate resources and share code.

Like containers, microservices are useful. But they’re primarily advantageous to developers. Gravitational traces this benefit to the fact that microservices abide by a software design that’s geared towards completing smaller tasks. As such, microservices make it easy for development teams to deploy code without interrupting other team members and scaling their services.

While independent, containers and microservices are closely related. Containers help to enable microservices in that they make it easier to break down tasks into smaller elements and share those portions with other team members. The problem is that microservices create security risks for organizations. Per Kong Inc., microservices use independent APIs to communicate with one another, thereby introducing additional channels through which malicious actors can attack an organization. Microservices also introduce the amount of logs through which security personnel might be sifting for signs of security incidents. If those services are running across multiple hosts, it becomes all but impossible for security teams to manually manage those logs.

Reliance on a Base Image

Organizations also need to be worried about the security of their container images. Per TechTarget, container images are static files that contain executable code. They leverage that code to run as isolated processes on an organization’s IT infrastructure.

The nature of container images makes these resources a security risk if organizations don’t know enough about them. As Kubernetes notes on its website, pulling container images from unfamiliar sources is tantamount to running unknown software on a computer. There’s just no telling what a container image could do in that scenario. It could conceal malware that could steal sensitive information or grant network access to a malicious actor. Along those same lines, container images could suffer from known security vulnerabilities; if unpatched, those flaws could give a nefarious individual all they need to gain access to the container environment.

Container Visibility

Containers are not designed to last for very long. The idea is for organizations to spin them up and wind them down according to their evolving needs. Via containers, organizations can quickly adapt to their emerging business needs by quickly and easily releasing software that corresponds with their customers’ preferences.

But this dynamism is inherently risky in that it makes it difficult for organizations to maintain visibility over their entire container environments. If they don’t know what’s in their environments, they can’t know how to appropriately protect their systems and ensure they’re secure. Not only that, but such dynamism also makes compliance a concern, as organizations can’t use firewall rules in the same way that they would with traditional, more static IT assets.

Container Communication

Containers aren’t isolated from each other. On another part of its website, Kubernetes explains that it doesn’t limit the communication flows between pods by default. This configuration enables pods to accept and send traffic between all other pods. In response, an attacker can compromise one pod and subsequently abuse this configuration to gain access to all other pods.

Container Configuration

Communication isn’t the only setting about which organizations need to be concerned for their containers. There’s also the issue of configurations. By default, containers are allowed to acquire new privileges. These rights make it possible for an attacker to abuse a container in order to access other parts of the container environment.

How Organizations Can Address These Risks

Organizations can address the risks identified above by implementing security best practices for the containers. Some recommendations to consider include:

• Use trusted base images only to build your containers: Organizations need to know where they’re getting their containers from and what content lies within them.
• Prevent containers from acquiring new privileges: Security teams need to specifically set this control to prevent malicious actors from staging a privilege escalation attack. They should also consider removing the setuid and setgid permissions in images.
• Adopt a policy of image scanning: Organizations need to frequently scan their images. As part of this process, they should reject or rescan images that haven’t been scanned recently before they move to the build stage. To streamline this practice, organizations should take the step of enshrining it in their governance policies.

The post ” 5 Risks You Need to Remember When Securing Your Containers” appeared first on TripWire

Source:TripWire – David Bisson