Cloud-Native Security: A Tipping Point for Security Teams’ Productivity
CISOs work 25 hours of overtime per week, according to recent research. Another study found that 73% of security professionals surveyed had resigned at some point in their careers due to burnout. This is true despite solid investment and growth in the function. Budgets are going up by 11%, and though many security teams’ roles go unfilled, only 10% of organizations said they were likely to cut cybersecurity roles compared to 20% in other areas. And this is after 90% had increased their security staffing in the last two to three years.
It is clear that security teams find efficiency elusive, but why? According to security practitioners, the main culprit is a disconnect between their toolset and the changing environments in which they operate. “The tools are dynamic; but not as dynamic as the threats themselves,” commented an IT leader at PBS Systems Inc.
Yet another security lead at VISA said, “Security teams need to protect so many new environments, including multi-cloud, serverless and on-premises, which drastically expand the volume of vulnerabilities, patching and updates. It’s hard to be as efficient with so much data and noise, so you have the same investment, but you’re not as effective.”
In terms of Kubernetes, teams must learn security from scratch with Kubernetes environments that “deviate from the design standard,” and they cannot yet “anticipate all the ways attackers could behave.”
Noise has Become a Pervasive Issue Across Cloud-Native Security
As the CEO of a VC-backed startup, I am always keeping an ear to the ground on the direction of talent as well as VC funding. A recurrent theme this year has been the placement of early-stage seed money in solutions that decrease the noise in cloud-native security and improve security teams’ overall efficiency.
‘Shifting security left’ was supposed to move some of the burden from security practitioners onto development, but this has also led to reduced visibility for security across heterogeneous environments.
Kubernetes has self-healing properties to automatically spin up or restart containers in response to disruptions or failed user-defined health checks. But in the case of Kubernetes, security-relevant expertise has moved over to engineering, creating the rare ‘security person that knows Kubernetes inside and out’ that is impossible to find or hire.
Attackers are now using the same fast-moving, resilient infrastructure tools as the blue teams left defending, and bots are outpacing automated defenses.
‘Buzzword hype’ has become an issue that teams have to navigate, causing security teams to waste time thrashing in different directions.
In sum, cloud-native application development (using containers, microservices, Kubernetes and migrating to the cloud) has caused a veritable maelstrom for security teams.
The CNAPP Example
Cloud-native application protection platform (CNAPP) is the buzziest term you can get today in cloud-native security. The appeal of the CNAPP is tool consolidation: Using one platform to consolidate image scanning, CSPM, runtime and all the security capabilities across the new app development lifecycle. Most vendors claim to be CNAPP, and Gartner has put out a few papers with an initial hypothesis on the topic.
Sounds great, right? Yes; if there was actually some time savings and efficiency to be gained. The recent Scarleteel attack showed attackers moving from a vulnerable web app in Kubernetes to a Kubernetes-hosted environment in the cloud to the cloud itself, ultimately attempting to steal AWS keys and compromise a cloud account.
CNAPP users would show the steps in the attack in separate screens and areas, and wouldn’t relate them to each other or show anything near to the fluidity across multiple environments shown by the attackers.
This is just one example of why security teams might say that “our tools are not morphing to the external environment.”
The Tipping Point
Today, cloud-native security is a net detractor from a security team’s efficiency and productivity. But, as a top engineering initiative, the migration to K8s isn’t stopping anytime soon. So how can cloud-native security stop being the factor that is pushing security teams’ productivity over the edge but in the wrong direction?
Practitioners had some tips for vendors:
1. Give me a real Signal, not noise reduction
a. I need meaningful insights from tools that morph into the environment – something that could follow the Scarleteel example above on one screen.
b. My SIEM is as good as the insight you put into it when it comes to the cloud.
2. Work with me to design your offering: I’ll give you time if I feel my input is being turned into value
a. How you sell your solution matters just as much as what you sell; stop pushing your agenda, listen and fill the gaps in your solution.
3. Allow me to turn it off
a. “I recently bought a runtime solution, and they keep showing me alerts, but what they fail to take into account is that I know what those alerts are and I’m okay with them. I am in the business of risk management, not ‘fix every single thing.’”
4. Help me create new models of influence and partnership across my organization
a. If my main stakeholder is engineering, then your tool needs to show stuff engineering will care about.
Conclusion
Despite the difficulty, the most forward-looking security teams find the challenges brought by securing new environments an exciting and rewarding endeavor. Teams are creating new models of influence and partnership across their organizations to cope, but only time will tell if cloud-native security will follow their lead to build a bridge of true partnership with these security teams or at least get them closer to their favorite 10-letter word (efficiency).
