As businesses transition to technology as a service, production workloads will continue moving to public cloud platforms and server types are expected to shift from virtual machines (VMs) and bare metal to containers and serverless platforms. The growing complexity is expected to complicate security.
Enterprise Strategy Group (ESG) analysts polled 371 IT and security professionals in the United States and Canada to create "Security for DevOps – Enterprise Survey Report," published today. All come from businesses mature in their use of public cloud services and containers, and all were responsible for evaluating, buying, and managing cloud security products and services.
Cloud-native applications are, and will continue to be, made up of heterogeneous microservices deployed across hybrid clouds, the report states. But while most organizations' current server types lean toward VMs and bare metal, their choices are predicted to shift to containers and serverless platforms within the next two years, researchers report.
When ESG conducted a similar study in 2017, it didn't ask about serverless functions "because it was just too early," says Doug Cahill, ESG senior analyst and group practice director for cybersecurity. This year, researchers found 34% of respondents use serverless "extensively," 18% use serverless on a limited basis, 16% plan to start using serverless within the next 12–24 months, and 28% are currently evaluating serverless. Only 3% don't have plans to use it.
"Organizations already deploying cloud-native applications are starting to strongly adopt serverless function calls," Cahill explains. "We also asked about the use of application containers, and that adoption has continued to grow over the last few years." The drivers for serverless function adoption include improved security (73%), network-based tech to secure against attacks (66%), security functionality embedded in source code containing serverless function calls (64%), and faster time-to-market when developing new applications (57%).
There are security concerns. API vulnerabilities (32%) are the top worry when considering serverless functions, followed by "exposure of secrets" (26%), API calls that result in unencrypted data transfer (22%), escalated privileges (11%), and use of unapproved APIs (9%).
While he is surprised so many businesses are using serverless, Cahill is not surprised at the overall mix of server types used in production. There is "still a really heterogeneous mix," he points out: 35% of respondents plan to use a mix of VMs, containers, and/or serverless.
The problem is, this mix of technologies compounds cloud security challenges. Cloud-native applications make it harder to protect hybrid and multicloud environments, researchers say.
Consistency is the biggest challenge. Forty-three percent of respondents are worried about maintaining consistency across their data centers and public cloud environments where cloud-native applications are deployed. Many believe existing security tools don't support cloud-native applications, so businesses often use multiple point tools managed by separate teams.
Nearly three-quarters (73%) of respondents say their organization uses too many specialized tools to secure cloud-native applications. This drives cost and complexity as organizations typically assign separate teams to use separate controls for separate environments.
"I think what we'll see is the convergence of cloud security point tools over time … and also the convergence of API security tools," notes Cahill. He hypothesizes there could be a single API security product to provide coverage across a range of programming languages and APIs.
Securing DevOps: A Shift in Mindset
DevSecOps is emerging as the primary means of protecting cloud-native applications. More than half (55%) of respondents have incorporated security into DevOps, and 22% plan to do so. Twenty percent are evaluating security use cases that can be built into the DevOps process.
However, only 8% of organizations are currently securing 75% or more of their cloud-native applications using DevSecOps practices. Researchers anticipate that number will grow to hit 68% within two years as DevOps teams create repeatable and scalable DevOps integrations. As more applications are secured with this methodology, the need for automation will increase.
Cahill points to a need to rethink the people, process, and technology behind development in order for this to work. With respect to the first two, "we need organizational alignment on making security share responsibility across all members of a product chain," he explains. While security has traditionally been "bolted on" toward the end of development, "it's really hard to bolt on security when you're doing continuous integration and continuous delivery (CI/CD)."
The two groups are historically different. DevOps is all about speed; security all about caution. DevOps thinks security will slow progress; security thinks DevOps is "running with scissors."
If you can integrate security with tools for CI/CD, Cahill says, you can securely move at the speed of DevOps. The move to include security in development is slow: While 52% of businesses involve the security team in protecting cloud-native apps before they push to production, many do so reactively: after an incident, for funding, or due to concerns around data stored in the cloud. One-third include security from the start of the development process.
In addition to involving security with the product team, Cahill points to another people-related challenge: ensuring both sides, but especially security, understand the attack types and methods adversaries are using. "What is different about apps that make them susceptible to threats?" he says. Once security professionals understand the points of vulnerability in APIs and serverless functions, they can better work with the dev team to secure them, he explains.