One complaint I often hear from stakeholders across the cloud security ecosystem is that there are way too many overlapping acronyms in cloud security. It’s confusing for buyers and counterproductive for the industry. Even worse, companies have deployed an alphabet soup of products, yet they are still exposed. Something’s got to give.

This is happening in great part because cloud security has innovated in ad hoc patches that don’t really relate to one another and address specific problems. Cloud Workload Protection Platforms (CWPPs) were inconsistently embedded into Cloud Native Application Protection Platforms (CNAPP). CWPPs and Endpoint Detection and Response (EDR) are now both targeting cloud detection and response use cases despite starting from very different territories, creating too many alerts and requiring too many configurations. Now add CSPM, a pivotal building block that keeps reinventing itself, to the mix along with Application Security (ASPM), Data Security in the cloud (DSPM), and Cloud Infrastructure Entitlement Management (CIEM). 

Confused? so am I.

While pundits believe that CNAPP will eventually become the “tool to rule them all,” what are security leaders supposed to do until then? Here are some strategies that guide the decision-making process: 

Take a holistic approach:

Don’t just think of cloud security in terms of shifting left – if anything, shift up to gain a top down view of the entire cloud lifecycle — from left to right. Look at your cloud security “from both sides (now)”: from a routine, everyday perspective – how do you prevent critically relevant vulnerabilities from being missed? How do you identify all risky connections and compromised postures? Can you harden your environment to protect against these? And from a “state of emergency” side – can you identify sensitive assets exposed during an incident? How soon can you spot the root cause and other critical occurrences? 

Leverage technology innovation:

The cloud has introduced a host of  emerging technologies that are propelling cloud security forward, but few are as impactful as Extended Berkeley Packet Filter (eBPF) is. eBPF can run sandboxed programs in a privileged context without requiring changes to kernel source code or load kernel modules. eBPF provides the attack monitoring capabilities of a robust agent, but with the footprint of a lightweight sensor, overcoming the technological barriers that have hindered effective attack detection. You can’t defend against a threat you can’t see, but eBPF can provide the “boots on the cloud” needed for effective cyberdefense in the cloud. 

Look for ways to simplify your stack:

In my experience, building a security architecture is part art, part science, and this conundrum requires both. When faced with intense pressure to act quickly, it’s beneficial to step back, slow down, and work with your team to get clear answers to questions such as “How will this purchase simplify my management burden today? Six months from now? Will I be able to stop using something else? Can I work with an existing vendor to include this functionality into a tool I already have deployed? How well can I convey the value of this purchase to the board? Will this solution help align security and devops teams? How?

Building a cloud security stack is about implementing measures and processes across development and runtime that map to the realities of the environment. Cloud security is complex, so the more you can simplify, the better. And rest assured, that starts with fewer acronyms. One acronym worth keeping, however, is KISS — trust me, you’ll need it!