Containers: Fueling Your Move to DevSecOps

The rapid adoption of containers in the enterprise represents a unique opportunity to shift security left. As a security leader, are you taking advantage of this opportunity? In a previous post, we discussed the intrinsic link between containers and public cloud. In this post, I’ll explain why containers represent one of the most vital opportunities to bridge the divide between development and security teams. Is it possible that containers could move your organization one step closer to DevSecOps? Before we explore this, here’s a brief history lesson to help us appreciate how we arrived at this position.

Figure 1: The Evolution of Modern Computing

"History doesn't repeat itself, but it does rhyme." – Mark Twain

Brief history

I like to think about computing as going through several evolutions. The first wave was client-server running on bare metal with a single OS and typically one app. The second wave came when VMware entered the server market in 2001. This ushered in the age of virtualized computing. The third wave brings us to the present with containers. Driving container adoption is the speed of DevOps and a desire to make applications portable. Still on the bleeding edge, and not currently widely adopted in the enterprise, is the fourth evolution: serverless or function as a service (FaaS). This represents a complete abstraction of compute whereby the consumer is hardware- and OS-agnostic. The two most recognizable implementations of FaaS are Google's Cloud Functions and AWS’s Lambda. With the history lesson behind us, let's dig into the Container Security Triad (see Figure 2) and how it can move security teams toward DevSecOps.

Figure 2: Container Security Triad

Build security

Getting security into the container build phase means you are actually shifting left instead of reactively at runtime. Think in terms of physical construction. The first thing one does before building a house is figure out what the desired end state looks like. It’s no different with container security. Build phase security should focus on removing vulnerabilities, malware, and insecure code. Since containers are made up of libraries, binaries, and application code, it’s critical that you establish an official container registry in your organization. Without question, one or more already exists. It’s the security team’s job to find the registries and quickly gain buy-in around getting access and setting security standards. The main goal of identifying and creating a standard container registry is to create trusted images. A process needs to be agreed upon and automatically enforced that no container be deployed from an untrusted registry. With over 2 million Dockerized applications, Docker Hub is probably the most recognizable container registry. This means it's also a great place to begin a conversation with your developers.

Deploy security

In the deploy phase, the focus shifts from making sure the materials used in building the house are without defect to making sure your teams are putting things together correctly. You can have an image that is without vulnerabilities, but if it's deployed to an insecurely configured Kubernetes pod, you haven’t sufficiently managed your container risk. Case in point: Unit 42 threat research found that 46% of organizations accept traffic to Kubernetes pods from any source. In the on-prem world, this is equivalent to deploying a server and then leaving it open “any any” to the internet. You wouldn’t do this on-prem, so why are almost half of organizations doing it in public cloud? Deploying to a secure configuration can be achieved by adopting a security standard for both your orchestration and container engine of choice. Don’t forget to put the necessary process and tools (i.e., guardrails) in place that will enable you to automate and monitor. The Center for Internet Security (CIS) has done an excellent job creating security benchmarks for both Docker and Kubernetes. They should be your starting point. If you get deploy security right, only the “good” should be making it into runtime.

Runtime security

The house is built, and it's serving its functional purpose, but systems do tend toward entropy (see the Second Law of Thermodynamics). Runtime security is about identifying new vulnerabilities in running containers and knowing what normal looks like. It also involves investigating suspicious/anomalous activities that could indicate zero-day attacks. If your security team was involved from the beginning (build phase), getting runtime security right is much less complex. If you’re coming late to the game and are reactively focusing on runtime, its best to work backward. Yes, it's important to make sure the end state is secure, but if your focus is narrowly on runtime, the same issues will likely repeat over and over. Interestingly enough, the IBM Systems Sciences Institute found that the cost to fix a bug during the maintenance phase (i.e., runtime) was 100 times more costly than if found during design.

“Security is a process, not a product.” – Bruce Schneier

Bringing it home

The rapid adoption of containers in your enterprise represents a unique opportunity to shift security left. When security is designed into the development cycle from the beginning, both security and development will feel an increased sense of ownership. This will happen because instead of security being a bolt-on “conversation” at runtime, the collaboration will happen all along the way. Organizations can achieve this by focusing security efforts on the Container Security Triad of build, deploy, and run. Security teams that do this as part of a holistic cloud security strategy may just find containers are exactly what they needed to move one step closer to DevSecOps.