Meeting the challenge of securing cloud-native apps [Q&A]

As more and more of our computing moves to the cloud, protecting information and apps throws up a new set of challenges for enterprises.

We spoke to Ratan Tiperneni, president and CEO of cloud-native app protection specialist Tigera, to find out more about the security implications of going cloud native and how to deal with them.

BN: What challenges do the new breed of cloud-native apps, especially those running on containers and Kubernetes, present to DevOps and security teams?

RT: As more enterprises adopt cloud-native architectures, specifically those running on containers and Kubernetes, security teams need to be aware of the different approaches required to secure their environments. While legacy architectures could reasonably be secured at the perimeter, cloud-native applications are too distributed and ephemeral for this approach. To address these challenges, security teams need to bring security controls down into the workloads themselves with an active security platform that automatically scans container images on demand and implements policies that set criteria under which images can be deployed. Further, DevOps and security teams should align their efforts to ensure security is considered throughout the development lifecycle.

BN: Why do infrastructure and security teams need a more holistic approach that shifts focus more on prevention and risk mitigation in addition to detection and alerting?

RT: If your only focus is on discovering known threats, you won't be able to keep up. This strategy leads to application teams being busy trying to fix last year’s vulnerabilities while new ones continue to pop up. Instead of forcing this legacy mindset, we need to implement active security.

Cloud-native application security is not an isolated concern but a collaboration between infrastructure and security teams. In adopting cloud-native architectures, development and security teams must take a new approach to developing and securing workloads. In practice, this means that security controls should be built into the architecture early to reduce the attack surface. Security teams should also consider the sheer volume of threats that may arise during runtime and work to implement mitigating controls in case of a security breach. This allows teams to combine prevention and risk mitigation with threat detection.

BN: How is zero trust a key part of this holistic approach?

RT: Given the size of the attack surface of cloud-native applications, a security approach that only focuses on vulnerability and threat detection is both impractical and inefficient. Instead, incorporating zero-trust principles to reduce the attack surface helps in actively preventing breaches from happening, as well as limiting the impact when a breach occurs.

Cloud-native applications running on Kubernetes are particularly vulnerable to the spread of malware because of the open nature of cluster networking; by design, any pod can connect to any other pod, even across namespaces. It's difficult to detect malware or its spread within a Kubernetes cluster without implementing a security model like zero trust. With a zero-trust approach, teams can minimize the blast radius of any potential intrusion by only allowing communication between pods when and where absolutely necessary.

BN: What are the current cloud-native security challenges and how can they be addressed with this new holistic approach?

RT: The speed of the CI/CD pipeline and the rise of cloud-native apps, containers and Kubernetes introduced new processes, policies, and fundamentals to existing application development and deployment.

Prior to cloud-native apps in containers and Kubernetes, DevOps teams would build an application, create an image, executable or installer and hand it off to the security team. The security team would then review the code for vulnerabilities, decide which servers to use and create perimeters around the environment. Once manual permissions were in place, the application would be deployed. With the automation of the CI/CD pipeline, however, the security team’s role has changed.

A holistic approach for optimal security and observability in cloud-native environments encourages active collaboration between security and DevOps teams. Security and DevOps teams must work together to ensure that security is built in at the beginning of the build process rather than as an afterthought. Together, security and DevOps collaborate to bring security to workloads, introduce compensating controls, and track images through to runtime. In doing this collaboratively, security teams will be able to catch any vulnerabilities before it's too late, and DevOps teams will be able to make any necessary adjustments to future developments based on the feedback provided by security teams.

BN: What are the security implications of increased innovation and cloud-native application adoption? How can organizations overcome the security gap created by increased innovation?

RT: The open nature of cluster networking is both the advantage feeding its adoption and the vulnerability that must be considered throughout the CI/CD pipeline. The rapid adoption of cloud-native architectures led to a rise in breaches, as many enterprises did not fully grasp the inherent differences between cloud-native and traditional architectures -- one cannot be simply ported to another without significant changes in design, process, and policies. It is generally understood that increased innovation introduces a greater number of unforeseen challenges. If moving fast and breaking things doesn't sound very palatable, then I have good news: the right way to ensure the security of cloud-native architectures is by being proactive.

Vulnerabilities of all types are rising at an exponential rate. An enterprise could hire every competent security team under the sun, but they would still be susceptible if they only address issues once they make themselves known. Instead, security teams must design their architectures with the assumption that they will be breached. With this understanding, teams can begin strategizing how to minimize the impact of said breach. This means implementing a zero-trust approach to reduce the blast radius and contain the spread from any vulnerable entry point. It also means that security and development teams must collaborate to prioritize vulnerabilities that would have the greatest impact and introduce workload-level compensating controls to tide over the vulnerabilities that pose only a minor threat. These strategies enable security teams to focus their efforts where they will have the most impact and allows enterprises to do more with less.

BN: What is Tigera? What is Project Calico and how has it developed?

RT: Tigera's story began six years ago with Project Calico, an open-source networking and security project with an active development and user community. Calico Open Source was born out of this project and has grown to be the most widely adopted solution for networking and security for containers and Kubernetes, powering 2M+ nodes daily across 166 countries.

As adoption of containers and Kubernetes grew and organizations started using Kubernetes at scale, they began to encounter more advanced requirements for observability and security. Tigera responded to this need by building upon Calico Open Source to create the industry’s only active Cloud-Native Application Protection Platform (CNAPP) with full-stack observability, available as a fully managed SaaS (Calico Cloud) or a self-managed service (Calico Enterprise).

Tigera was founded by the original Project Calico engineering team. We are committed to maintaining Calico Open Source as the leading standard for container and Kubernetes networking and security, while also offering Kubernetes-native, full-stack security and observability capabilities to commercial users looking for a pay-as-you-go, managed cloud service or a self-managed, on-premises platform.

Image credit: jirsak / depositphotos.com