Mitigating Controls for Cloud-Native Applications: Why You Need Them

Originally published by Tigera.

Written by Phil DiCorpo, Tigera.

Fixing vulnerabilities can be hard—especially so for cloud-native applications. Let’s take a deeper look at why this is, and how mitigating controls can help secure your cloud-native applications.

Vulnerabilities are like earthquakes—its best to be prepared

The trials and tribulations of Log4j are now safely in our rearview mirror. Most of us responsible for operating a container platform like Kubernetes have navigated through the remediation efforts and disaster has been averted.

But it was a wake-up call for many, and at the very least a healthy reminder for all of us. There have been many infamous vulnerabilities before Log4j, and much like living in an area of the world where earthquakes can strike at any moment, much can be learned from the big ones that came before.

When Heartbleed was publicly disclosed in 2014 it sent shockwaves around the world. It was a critical vulnerability in the ubiquitous OpenSSL library—a cryptographic software library that is used to implement the Transport Layer Security (TLS) protocol. Most of the web relies on TLS to secure communication between clients and servers, and the vulnerability came about through a simple bug that resulted in improper input validation for heartbeats.

The bug existed in OpenSSL for a whopping two years before being publicly disclosed, and as the announcement made headlines around the world, the race was on for operators to remediate the issue. 30 days into the effort, over 12,000 of the most popular websites were still vulnerable. Why? Remediation was not easy. Patching server software could involve rebooting and incurring downtime. Given how long the vulnerability went undetected, you also had to assume that you were compromised, which meant provisioning new certificates. And if you were dealing with user authentication data, you also had to initiate the painful process of a password reset. Remediation was hard and the business impact was significant.

Enter stage left: The containerized application

Just around the same time as Heartbleed, a seismic shift started that would change how we build, deploy, run, and patch software. Docker and containers came charging onto the scene and started to revolutionize software development.

Along with the rise of open source software (OSS), containers meant you could build complex software more quickly than ever before. The “Lego kit” for development teams and cloud architects grew to include a dizzying array of 3rd-party components, from NGINX and Envoy to Postgres and MySQL.

While OSS and containers have accelerated the development and delivery of software at unprecedented scale, they have also compounded the challenges of security and timely vulnerability remediation.

In addition to the complex dependencies that can exist between the software your teams develop, the idea of a software supply chain has become a very real thing and is yet another dimension of cloud-native applications that adds complexity to vulnerability scanning and remediation. Your applications likely depend on an increasing number of containers and components from 3rd-party vendors and projects. As a result, it could take weeks or longer to patch the affected components and release new software when a critical zero-day vulnerability is announced.

It’s a bird, it’s a plane… It’s mitigating controls!

This challenge of remediation is not a new one, and mitigating controls have traditionally been the way that IT organizations and security teams could buy time to deploy a fix. Mitigating controls are additional layers of security that mitigate the risk of attackers exploiting vulnerable software components. They help reduce risk and provide a way to minimize the impact on business operations while remediation efforts are underway. For traditional infrastructure, this included temporary security measures that were deployed in firewalls, secure web gateways, proxies, and endpoint security tools.

The problem is that very few of these tools exist for cloud-native container platforms, whether it’s EKS, AKS in the public cloud, or OpenShift or RKE on-premises. Traditional security tools were designed for traditional infrastructure. As the distributed architecture and supply chain of cloud-native workloads have become more complex, the options for deploying mitigating controls as part of your container security initiative are limited at best, and non-existent for most.

Why you need active security for cloud-native applications

While DevOps teams and platform operators have started to use tools to scan container images for vulnerabilities, they often do not have adequate facilities to manage risk while application teams work through the process of releasing new software to remediate these vulnerabilities. DevOps teams and platform operators need a way to continuously assess first and third-party images for vulnerabilities and automatically block deployment of images that fail to meet security requirements. They need a single platform that offers image assurance.

Let’s say the latest scan results show a critical vulnerability running in a half dozen workloads in your production Kubernetes cluster. Your application teams say it could take several weeks to patch the software, update dependencies, and do regression testing. What do you do in the meantime?

You need a security platform that makes it easy to visualize the communication for these affected workloads, and can use associated flow logs to recommend a security policy that is automatically staged in your environment. This platform should be able to audit staged policies before they are actively enforced, giving you greater assurance that applications will not be negatively impacted. Once the policy is enforced, controls should only allow the communication required by the current version of the application and help mitigate the risk of exploitation.

While much of application development has changed since the days of Heartbleed, the challenges of vulnerability remediation have not. If anything, complex software supply chains and the scale of cloud-native development has made it more difficult. You need a platform that provides the tools to identify vulnerabilities and an “easy button” for mitigating controls to buy your application teams time to fix them.

To learn more about how to adopt a holistic approach to container and cloud-native application security and observability, read our free O'Reilly ebook.