Why the Age of the Cloud Native Security Platform Is Here to Stay

By John Morello, vice president of product, Prisma, Palo Alto Networks

The writing is on the wall: Traditional security tools and methodologies are ill-suited to protect cloud native’s developer-driven and infrastructure-agnostic multicloud patterns. It’s now time to enter the Age of the Cloud Native Security Platform (CNSP).

Infrastructure as a service (IaaS) was largely about taking existing infrastructure and operational patterns and moving them to environments that could be more easily scaled. The underlying business model was largely consumption-based. Because the base patterns and technology stack largely didn’t change, the contemporary security tools of the age could easily ride along for this transition and simply be “lifted and shifted” to run on those IaaS platforms. But over the past four years, we’ve entered the cloud native age, which is defined by shifting focus to higher-value outcomes rather than simply faster deployments and a shift from CapEx costs.

Cloud Native Technologies Take Center Stage

Cloud native empowers digital transformation by leaving undifferentiated IT infrastructure to the providers and freeing organizations to focus on building and running apps that deliver competitive advantage, connect their workforces or serve their customers. As defined by the Cloud Native Computing Foundation:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure and declarative APIs exemplify this approach.

CNSPs are optimized for this app-centric, infrastructure-agnostic world. They integrate with the development lifecycle, are programmatically accessible via APIs and run everywhere the apps do.

The Demand for a New Security Paradigm

A CNSP isn’t a response to a singular new type of threat, nor is it simply a remixing of existing technologies behind a new set of buzzwords. Instead, it’s a platform-centric approach to security, optimized for the cloud native architectures and operational practices of the present and future. A CNSP is aligned with not just the underlying infrastructure but also with how users build and run apps on it. It recognizes the diversity of modern app topologies and the criticality of protecting them throughout their lifecycle.

Thus, a CNSP can be defined as providing a comprehensive, programmable security platform across two dimensions: time and technology.

Security practitioners have long acknowledged the benefit of applying security early in the lifecycle of apps. The earlier problems can be identified and corrected, the less risk they expose organizations to and the lower the cost to resolve them. However, the IaaS Age and preceding generations of computing weren’t conducive to actually making this vision a reality.

When development and security operations aren't just separate teams but entirely separate disciplines with distinct artifacts and tooling, it’s impractical to have a consistent way to monitor and enforce security from developer to deployment to operation. Cloud native fundamentally changes this equation by emphasizing a more integrated approach to building and running apps, enabled by modern tooling like containers and serverless that make this integration a practical reality.

A CNSP provides security visibility and control from the first time an app is built throughout its operational life, wrapped in APIs and tooling that emphasize automation and developer experience.

Putting the Security Puzzle Pieces Together

Last year we wrote about the continuum of cloud native compute options: the notion that cloud native isn’t about a journey from VMs to containers and serverless but rather about a range of different options for running workloads, each with its own strengths and weaknesses. On one end of the continuum are VMs, which emphasize compatibility and control but require greater management effort. On the other end is serverless, which optimizes for density and developer agility but at the cost of control and backward compatibility. And here is where a critical observation has emerged: The reality of what we see with customers is that it’s not a journey from one side to the other but rather a pragmatic, per-workload decision. A legacy database may be well suited to stay in a VM whereas the front end of a new mobile app may be a better fit for serverless.

Organizations are choosing an “all of the above” approach to compute but one consistent goal is to have a unified security capability across all options. Few organizations would actively want to have siloed security tools that only address part of the continuum. In the age of IaaS, cloud workload protection platforms (CWPPs) tried to protect across some of these options, typically just VMs. However, a CNSP provides coverage across the continuum of compute options — from VMs to containers to serverless and everything in between. This allows organizations to choose the right compute option for any given workload without worrying about how to integrate disparate solutions for monitoring and defense.

Compute is only half the technology stack, though. Modern apps are often built as a composite of general-purpose compute components that run on the continuum and PaaS services provided by the cloud platforms. Just as a user may choose to run a database on a VM and a mobile front end on serverless, they may also choose to run that database on a Database as a Service (DBaaS) platform or use a service such as Elastic Beanstalk to run the front end.

Cloud providers use the concept of a shared responsibility model to describe the fact that they’re responsible for meeting the security SLAs of the underlying services — securing the physical data centers, providing the controls to limit role-based access and so forth — but customers are responsible for secure configuration of those services.

Shared Responsibility Is a Three-Layered Cake

It can be helpful to think of this shared responsibility model as having three layers. Providers are accountable for the bottom layer of infrastructure and finished services. Customers are accountable for how they configure these services and what they run on them. In the age of IaaS, cloud security posture management (CSPM) tools were used in an attempt to provide visibility of these services’ configurations — but without any insight into the accompanying compute that ran on top of and alongside them.

Consider the example of a service like AWS Lambda. While Amazon runs the underlying service in accordance with its SLAs and terms of service, this policy only provides the opportunity for a customer to be secure. If the customer configures Lambda with incorrect security groups, the applications and data will be exposed to greater risk. That’s the traditional CSPM aspect of the stack. However, even with a CSPM tool monitoring-service configuration, if the user runs a Lambda with critical vulnerabilities, it can be compromised and abused to attack other resources or exfiltrate data.

A CWPP tool may be able to detect these vulnerabilities and stop these attacks but, in isolation, it can’t determine if the function is configured with the wrong security group. Multiply these silos across the hundreds of services in use across tens of regions in dozens of accounts across several cloud providers and these gaps become practically unsolvable. A CNSP thus must be able to provide monitoring, visibility and remediation of these provider layer components while also correlating data and applying policy across the compute components of cloud native, composite apps.

A Cloud-Agnostic Security Future

Increasingly, organizations are becoming intentionally multicloud. Whether this be for vendor management, data locality or other reasons, large organizations rarely only use a single provider. While cloud providers have added security capabilities at both layers of the stack, these capabilities are focused on their own services and don’t provide visibility across clouds. A CNSP protects the time and technology dimensions across multiple clouds, such that organizations have a single platform on which to automate security regardless of where the underlying services and compute reside.

As comprehensive platforms, CNSPs must provide a wider range of security capabilities than the point solutions of the Age of IaaS. CNSPs include the following capabilities:

• Inventory and classification
• Compliance management
• Network Security
• IAM Security
• Data Security
• Vulnerability management
• Workload security
• Automated investigation and response

While some of these are more relevant at certain phases of the lifecycle or layers of the stack than others, all of these capabilities should work together in tangible ways to provide stronger security than even best-of-breed point solutions in isolation. For example, while runtime defense may not be performed in the development phase of an app’s lifecycle, a CNSP should be able to automatically inform a development team of a new threat to its app identified in production and suggest methods to remediate it in the next build.

Cloud Native Orgs Require a Cloud Native Security Platform

The Age of the CNSP is a fundamental shift in the way that enterprise security has traditionally been delivered. The cloud native ecosystem and operating mentality create challenges that traditional security approaches aren’t able to meet, but also provide the opportunity for delivering security that’s more integrated, autonomous and ultimately effective. CNSPs provide protection across the entire lifecycle of apps, the entirety of technology stacks they run on and all the clouds they run in. CNSPs are built as true platforms, using rich APIs and open data formats. Just as cloud native itself fundamentally changed how the cloud is used, CNSPs are fundamentally restructuring how it’s secured.

Interested in learning more about cloud native technologies and innovation in cloud native security? Explore Prisma Cloud, our Cloud Native Security Platform.

This post originally appeared in The New Stack.