Over the past 18 months, containers have taken most organizations by storm. Containers and microservices are key enablers in organisations’ quests for digital transformation. But, they increasingly need to adopt a smart cloud security strategy based around a Container Security Triad.
Every executive is undoubtedly worried about cyber risk. But I’ll bet many are likely overlooking a major gap in a cloud strategy: A hole in Docker aka the most popular software container platform in the world.
As more organisations migrate workloads to the public cloud, technology teams are likely knee-deep in containers and microservices that run within them. This should be, in part, good news because containers and microservices are key enablers in the quest for digital transformation for several broad reasons that are worth repeating.
Microservices reduce complexity by treating software as small, digestible, agile pieces of code delivered as a “service” rather than as a traditional software program. Microservices increasingly are replacing those hulking, expensive, difficult-to-deploy legacy applications that have dominated data centers for decades.
Containers promote portability, allowing applications to run in the most appropriate and flexible location — public cloud, private cloud, on-premises, or on either physical or virtual infrastructure. Containers are fairly lightweight given that they don’t contain an operating system like a traditional virtual machine would.
Containerized environments have many more layers of abstraction that require specialized tools to interpret, monitor, and protect these new applications. In a production container environment, there are several different layers to secure.
Thus far we’ve extolled the positive side of containers, but there is a dark side, as well. When it comes to managing the new risks brought forth by containers, many security teams are taking one of two approaches.
The first, and unfortunately the most common path, is to completely ignore them. This is never a good strategy. The second is when teams attempt to address the risks tactically with yet another security point product. Both of these approaches will almost certainly not end well.
Fig. 1: Container Security Triad: Build – Deploy – Run
Need for a Holistic Cloud Strategy
From a security perspective, the true value of containers and microservices can only be achieved when they are secured as part of an overarching cloud security strategy that is based on standards. Organizations over the past decade have fallen into the trap of thinking that more security tools equal better security. Unfortunately, we now have more security tools than ever before, and yet breaches continue to be reported at a torrid pace. More security tools do not equal better security.
Which brings us back to the “hole in Docker” point. In early 2019, there was a troubling development: a critical vulnerability was reported that affected the underlying program that supports Docker and other related services. This vulnerability was extremely serious, as it allowed an attacker to completely control the container as well as any other containers running on the platform.
If an organization has taken steps to craft comprehensive cloud security programmes — ideally that should include what I call the Container Security Triad—then they are well-positioned to avoid the headaches and risks this vulnerability, and others like it, can cause. Of course, if they don’t have a comprehensive cloud security strategy inclusive of containers and microservices, now might be a good time for that conversation.
Adopt the Container Security Triad
The Container Security Triad (fig. 1) has three critical elements in its risk mitigation framework — build, deploy, and run. When teams are creating containers, this is the build phase. The security team’s focus should be on detecting and remediating known vulnerabilities, as well as identifying new vulnerabilities (commonly known as 0-day).
Deployment security is a critical part of the equation because it helps to ensure that poorly constructed containers don’t make it to production. Think of it like a general contractor building a house, checking to ensure that the materials used in the construction process are defect-free.
Runtime brings additional risks. Runtime security focuses on protecting running containers and related infrastructure such as Kubernetes, the Docker engine or the underlying host. The most effective way to manage risk is to measure the containers’ behaviour against a known baseline. If you know what’s normal for the container, you can take aggressive action when you see a deviation from the baseline. This is another benefit of containers. Since they typically do only one thing, it is straightforward to pattern their behaviour and notice when there are anomalies.
No Such Thing as ‘Too Fast’
Many CEOs, board members, and business executives are hearing a lot about the benefits of containers and microservices and are becoming very comfortable with the idea that these technologies are helping their organizations become more agile, more resilient, and more digital. But they should also be aware that there exists the potential for an “interesting” conflict within the organization regarding just how fast they should embrace and adopt containers and microservices.
For instance, if you talk to the software engineering team in the midst of DevOps mania, they will tell you they can’t move fast enough without containers and microservices. But the security operations team, charged with ensuring the highest possible level of cybersecurity, may not always share that enthusiasm.
Containers and microservices are inexorable forces that not only speed the release of new software, but also can aid greatly in reducing the complexity of software code that too often is at the root of cybersecurity vulnerabilities. That’s where the Container Security Triad comes into play; properly planned and executed, it can ease the “shift left” mentality for security that is often referred to as DevSecOps.
How should leaders and teams who are cybersecurity experts and executives investigate the health of the security of their cloud-native computing?
Here’s a short checklist to consider:
- If we’re using containers, are they integrated into our overall cloud security strategy? If they’re not, it’s a good time to ask why and how they are currently addressing it. If they’ve taken a tactical approach with a security point product, that is not a good path forward, given the proliferation of security tools in most organizations.
- How does your container security strategy address people, process, and technology within the overall cloud security framework? Let’s be honest, too many CISOs still view cybersecurity as a technical domain. This is a mistake, because security is a process, not a product
- How are containers and microservices impacting our cloud security risk profile? It’s great that the DevOps teams will be releasing software faster and with greater measurable impact on the bottom line, but they must also be able to tell you how containers and microservices are reducing cyber risk.
If we remove complexity—whether it’s with containers, microservices, or any technology that facilitates agile, reliable delivery of IT services for the business—we are on the path to make the enterprise more secure. By contrast, if we make things more complex by layering on even more security tools, we not only increase complexity, but also risk.
Chief Security Officer, Public Cloud, at Palo Alto Networks