EC News DeskEvery executive is undoubtedly worried about cyber risk. But I’ll bet many of you are likely overlooking a major gap in your cloud strategy: A hole in your Docker. No, I’m not talking about a tear in your casual Friday attire. I’m talking about Docker, the most popular software container platform in the world. While you may not be well-versed on containers, or the applications that often run inside them, microservices, I can guarantee your CTO, CIO, and developers are keenly familiar with them. In fact, if your organisation has migrated workloads to the public cloud, your teams are likely knee-deep in containers and microservices.
This should be, in part, good news because containers and microservices are key enablers in your quest for digital transformation. Over the past 18 months, they have taken most organisations by storm. You need to be aware of them and ask your teams the right questions to move your organisation forward, faster.
I won’t make your eyes glaze over with arcane technical details, but here’s what you need to know:
- Microservices reduce complexity by treating software as small, digestible, agile pieces of code delivered as a service rather than as a traditional software programme. Microservices increasingly are replacing those hulking, expensive, difficult-to-deploy legacy applications that have dominated your data centres for decades.
- Containers promote portability, allowing applications to run in the most appropriate and flexible location, whether 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.
- Containerised environments have many more layers of abstraction that require specialised tools to interpret, monitor, and protect these new applications. In a production container environment, you have a number of 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.
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. Organisations 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.
Take heed, dear reader.
Which brings us back to my hole in your Docker point. In early 2019, there was a troubling development: a critical vulnerability was reported that affected the underlying programme 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 your organisation’s CISO or CIO have taken steps to craft comprehensive cloud security programmes, ideally that include what I call the Container Security Triad, then you are well-positioned to avoid the headaches and risks this vulnerability, and others like it, can cause. Of course, if you 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 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 your 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.
There’s 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 organisations become more agile, more resilient, and more digital. But you should also be aware that there exists the potential for an interesting conflict within your organisation regarding just how fast you 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.
Tips for the C-suite
How should executives talk to their CISO, CIO, or CTO about containers and microservices? Some suggestions for you:
- 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 organisations.
- 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 making 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.
By Matthew Chiodi, Chief Security Officer for Public Cloud at Palo Alto Networks.
