Your Risk is Shifting to Places You Can’t See

Gaining Visibility into NIST SP 800-190, Part One

I’m penning this blog post on the heels of KubeCon 2019. This was my first KubeCon, but I doubt it will be my last. I can’t tell you how many times this year I’ve heard or been pitched the idea that security tools are “shifting left.” As much as it’s a worn-out theme in our industry it’s also largely true and hence my first KubeCon. I wanted to see what was driving the need for this new eco-system of tools firsthand. More importantly, for me and the cybersecurity industry, I wanted a peek into the unknown unknowns. Just what are these developers up to?

With the broad adoption of orchestration and containerization platforms, it almost seems there are limitless ways to develop and deploy applications. The shift from traditional application deployments to virtualization and on to those delivered through containers allows for faster application development and delivery, while introducing additional abstraction layers of complexity. These additional layers of complexity have only amplified the need for visibility and security in these environments.

Container adoption has been driven by the fact that containers can be deployed and scaled independently in multiple environments and they only use the necessary software to perform a task, limiting unneeded overhead. However, this process requires a container orchestration platform – like Kubernetes – to provide a streamlined workflow for managing, scaling and providing container metrics, such as resource utilization.

The pace of innovation I witnessed at the conference was breathtaking. Who are all these companies? How’d they spin up so fast? And what are the security implications of the shift in how modern applications are architected?

To help guide security practitioners through the massive changes taking place, our team has been laser-focused on several of the prominent cybersecurity companies within the container space. Not only have we been paying close attention to the technical aspects of the features offered by these solution providers, we’ve done our best to embrace DevOps/DevSecOps ourselves. To get hands-on we adopted developer workflows to the extent that we could. Code repositories, CI pipelines, declarative infrastructure, cloud native, yes to all that.

To move beyond the tools described in our last research project on IaaS security, we needed actual applications to run on this infrastructure. It’s hard to evaluate how container security tools function without containers, right?

Taking a developer-first approach, we set up an instance of Gitlab Enterprise Edition and cloned the repositories for Sock Shop and Robot Shop. On the infrastructure side we utilized tools like Hashicorp’s Terraform to spin up Kubernetes clusters on AWS EKS. Then we started rolling out our test applications via a CI/CD pipeline. Undeterred by failure, we literally hacked away at the learning curve of modern application development and several dozens of commits later we were pushing functional code to our clusters.

This was a minor, but important accomplishment, considering that we now needed to tackle all the security aspects of what we’d put together.

We’ll use NIST SP 800-190 Application Container Security Guide as the basis for the series. This standard outlines five areas of major risk for the components of container technologies: image, registry, orchestrator, container and host OS. Within each area we’ll take a look at what tools are provided by AWS as well as what other third-party tools are required to gain visibility into container environments.

Stay tuned for Part Two, which will detail our lab environment.