As excitement around container technology continues to grow, many questions remain regarding the best way to secure them from both a technical and organizational perspective. While developers and DevOps are usually the first to see how containers help streamline their work and are aware (to a degree) of the security challenges, they do often lack the expertise required to integrate them.
Security professionals, on the other hand, are still lagging behind in understanding the technology and new threats that it may bring. This knowledge gap is something we’d like to bridge. To that effect, we have outlined, below, best practices for creating a viable security program.
Developer <> Security Team
One of the challenges is the current disconnect between DevOps and security priorities. DevOps’ main mission is to get the product out as fast as possible with as little maintenance as possible, and security is a necessary evil. Security teams, on the other hand, lack visibility and have difficulty validating containers leading up to and during production.
In enterprise environments, goodwill on both sides can only go so far. Security must fulfill stringent requirements for compliance, reporting, and threat mitigation. “Best effort” is often not enough, and full visibility is required.
Threats to Virtualized Containers
Potential attack vectors that threaten containerized applications can be grouped into several types:
1. Threats to the Build Environment
The build environment should be on the top of your security checklist, primarily because developers can’t be expected to all be security experts. The developer has an interest in building the product as quickly as possible, which means that they do not have time to test data management or masked data.
Furthermore, bugs in the source code, alterations to automated build controllers, and insecure open-source libraries, among other factors, can introduce serious vulnerabilities into the system. Failure to thoroughly audit the entire build environment process can lead to bigger problems that will be more difficult to solve down the road.
2. Container Security
Does the container include tools like ssh, which allows content to be easily changed? Is the operational security and underlying container host protected via appropriate mapping access to OS and host resources? Have hardened security features been used and how have they interacted with the container? The truth is most people in security operations won’t know the answers to any of these questions. The operations team will most likely not even know what is in the container, which means everyone needs to be brought up to speed.
3. Vulnerabilities in Containers
Especially when using open source base images, vulnerabilities may be introduced into containers. These vulnerabilities may arise by failing to update the machine with newer patched versions, improper configuration, and can be exacerbated by cyber attackers actively looking to take advantage of these vulnerabilities.
4. Platform Security Issues
The goal here is to block all but a subset of resources that the container must access in order to run the application, i.e. rigorous application of least privileges. Why? What could go wrong if that’s not done? If the container attacks the underlying OS or the container engine itself, the impact would be significant. Such an attacker could own the host, and from there easily spread to other systems.
Container Security Is Here to Stay
Although container technology and security are still in the early stages, a lot of the tools needed to deliver and manage container security are already available. DevOps and security do not have to battle it out. With the right procedures, and by assembling a container security program, organizations can continue to enjoy the significant advantages of containers, while compliance and security are adhered to as well.