A recent report from Venafi found that 80% of companies have experienced a security incident in the cloud over the past year. Many other reports will also sound the alarm about API security incidents, the use of stolen credentials to gain unauthorized access, and the unfortunate successful rate of phishing attacks.
The state of security is, to be frank, a constant nearly Sisyphean battle uphill while the sword of Damocles continues to swing overhead. Too many Greek mythology references? Yeah, probably.
But it's apropos of the situation. There are security risks in the code, in the more than 80% of app components sourced from public registries and repos, in the vulnerabilities up and down the IT stack, and of course, the omnipresent threat of more traditional volumetric attacks.
You’ll note I haven’t mentioned “cloud” yet. That’s because a coding error vulnerability is a coding error vulnerability no matter where the app is deployed. SaaS? Still a vulnerability. Cloud? Vulnerability. On-premises? Yup, still a vulnerability. Sourced an app component from an OSS project with a vulnerability? Still a vulnerability no matter where the app is deployed.
I wish I could say, "here's a magic wand; it will address every security issue you have – in the cloud, on-premises, and on every endpoint you manage," but I can't because it doesn't exist any more than the “single pane of glass” for operations exists.
When it comes to angst over cloud security, the real source is really about the (in)consistency of services and solutions that make it difficult to “apply consistent security policy across all company applications.”
For the past four years, we've been asking about multi-cloud challenges. Guess which challenge always ranks at the top? You're right—applying consistent security policies. And yeah, it's at the top again this year. Like that's a surprise.
This challenge exists because multi-cloud is inherently complex, especially when you start adopting different security services and solutions in every cloud. Yes, using the native security service to protect your APIs might be easier to implement from an operational perspective, but not from a security perspective. It’s like asking the folks responsible for those policies to learn a completely new language for each environment.
Imagine if you had to learn a new language every time you traveled abroad. Going to France? Learn French. Singapore? Mandarin. Somalia? Somali.
It’s the same for cloud security. Every time a new service or solution is adopted, the policy language has to be learned so organizational policies and configurations can be translated correctly.
The root cause of multi-cloud complexity is that every cloud, every service, every solution, and every console is different. Cloud models are inherently unique because they were built by providers from the ground up with very different ideas of how to architect a highly scalable and efficient complex system.
There are no standards, no common definitions, taxonomies, or workflows. Each cloud has its own way of doing things, and that way may not align with how your company does things.
So you can pretty much extrapolate what that means for security. Standardization is one of the ways organizations have always addressed the need to scale efficiently, and security is no different.
The need for speed—and standardization—is one of the core drivers toward the adoption of security as a service. We see this in data points from every source—industry, analysts, and anecdotal stories. Security as a service—typically at the edge—is growing as a strategic means of standardizing security practices that span all applications, no matter where they are deployed.
Security as a service effectively addresses multi-cloud’s biggest challenge: consistent security across all applications. It’s no surprise that the market for it is growing rapidly, with no signs of slowing down.
You can’t get rid of multi-cloud complexity, but you can eliminate its impact on security by standardizing services and solutions that are built to serve a modern, multi-cloud portfolio.