Cloud security is not easy to explain. There are cloud security frameworks that help organize what cloud security should be or what it should not be. But there are also so many frameworks that confusion in cloud security is inevitable. Which frameworks help, if any?

One of the things that makes this so confusing is that there are numerous different cloud acronyms that explain different cloud security frameworks—it's worth explaining what has become a kind of acronym bingo. There’s cloud security posture management (CSPM), cloud workload protection (CWP), and a newer emerging approach called cloud-native application protection platform, or CNAPP. Let’s not forget cloud identity and entitlement management (CIEM), which is focused on least privilege access and resource entitlements in the public cloud.

But when you are building apps and consuming public cloud workloads from Amazon Web Services, Google Cloud Platform (GCP), and Azure, how do you build a cloud security program? The major challenge is cloud applications have become arguably one of the most significant attack vectors, and definitely the most dynamic attack vector, where old security tools and programs really struggle to add a lot of value. This is a coverage problem that every security team must deal with these days.

Tools and acronyms aside, when building a comprehensive cloud security program, organizations need to focus on three primary priorities.

The first priority is guardrails. Can you create guardrails against obvious misconfigurations that will lead to a data breach? How many times have we heard about a company which has built something on Amazon or Azure only to have their S3 bucket hacked; or their Firebase, Elastic DB, MongoDB, or Azure databases compromised, often due to a misconfiguration? The good news is there are more options each year for basic security guard rails in the cloud, and the prices are finally coming down.

Following basic guardrails, the second priority for a cloud security program is protecting the workloads, apps, and the services being used by the DevOps teams. It’s ultimately the organization’s responsibility to continuously identify and remediate vulnerabilities and policy violations. These cloud security remediations should happen in pre-production with the ability to enforce controls during application runtime in production. This will never be the responsibility of Amazon, Microsoft, Google, Alibaba, or any other public cloud provider. Every piece of software written on top of their infrastructure and APIs is the customer’s code and the customer’s responsibility. That’s the shared responsibility model of cloud security, which has been lagging in adequate investment by most organizations, as evidenced by the growing numbers of cloud security compromises within business applications.

The last cloud security program priority is a growing trend that goes beyond just basic reporting and auditing—observability is top of mind for all development, security, and operations (DevSecOps) programs. Observability means looking at environments not just through the lens of compliance but also through the lens of risk. Evolving from just monitoring to observability needs to be a major area of investment for organizations to fully understand what the cloud environment looks like. It’s a requirement that turns out to be critical but non-trivial in the public cloud.

In considering new approaches to cloud security, why should we care about cloud-native application protection platforms (CNAPP) as yet another confusing cloud security acronym? The answer is that the principles outlined in CNAPP address three very important areas: Application Artifact Scanning (pre-production), Cloud Configuration (guardrails to protect underlying services), and Runtime Protection (production observability and defense).  

For more details beyond this article, read this full Gartner CNAPP report.

The first area of protection in CNAPP is at the genesis of the app or when the software is being created and put into the cloud environment. Whether it's in staging, pre-production, or test-and-development, this is where you need enhanced scanning. This is nothing new for application security (AppSec) programs, which have long maintained static analysis, dynamic analysis, software composition analysis, and application programming interface (API) scanning and discovery. This step ensures as the app is forming, developers understand it and have a record of it and can conduct security analysis before it gets pushed into the production runtime environment. When CNAPP is working well, it can leverage AppSec scanning results and feeds them into the next two stages of configuration and runtime.

The second principle of CNAPP is cloud configuration. Whether this is CSPM or best practices of cloud configuration, this is essential. Many of the most significant data breaches that have happened in the cloud can be traced to cloud misconfiguration as the root cause. CNAPP’s guidelines for cloud configuration are broader than CSPM because they start to tap into the application and API layers that go beyond just infrastructure scanning. Also, CNAPP audits for least-privilege access enforced by identity access management (IAM) and cloud identity and entitlement management (CIEM).

The third area for CNAPP is runtime protection, and this comes from a heritage of installing firewalls, Web Application Firewalls, and Endpoint Detection and Response agents. This approach enables blocking bad traffic and attacks during application runtime. But when you take the tools from the old firewall and traditional on-premises data center eras, along with Windows agents, and try moving them into a cloud-native environment, the tools have mostly fallen short and it's created significant risk for organizations. CNAPP’s approach to runtime protection often focuses on observability first followed by enforcement at the application layer second. Using tools built for cloud applications that do not require traditional agents or network gateways are key distinctions for CNAPP runtime enforcement. Also, CNAPP runtime protection will often embed SDKs or other application-layer extensions to complement traditional network enforcement.

Based on all the available frameworks, CNAPP is the most comprehensive approach for addressing three of these critical security areas for protecting cloud-native applications and sensitive data. Organizations should look to build their cloud security programs with tools that are application-centric by default, and can easily perform configuration analysis and runtime protection analysis for APIs and the apps that run on top of these cloud environments. Once these API and runtime protections are in place, organizations can be assured that they are on the right path toward enhanced observability and protection controls of their cloud workloads.

Doug Dooley is COO at Data Theorem.

Image: Reuters.