Yes, there are security ramifications to serverless computing
At least one in five organizations, 21%, have implemented serverless computing as part of their cloud-based infrastructure. That’s the finding of a recent survey of 108 IT managers conducted by Datamation. Another 39% are planning or considering serverless resources.
The question is, will serverless computing soon gain critical mass, used by a majority of enterprises? Along with this, what are the ramifications for security?
Existing on-premises systems and applications — you can call some of them “legacy” — still require more traditional care and feeding. Even existing cloud-based applications are still structured around the more serverful mode of development and delivery.
That’s what many enterprises are dealing with now — loads of traditional applications to manage even while they begin a transition to serverless mode. Again, even if applications or systems are in the cloud, that still is closer to traditional IT than serverless on the continuum, says Marc Feghali, founder and VP product management for Attivo Networks. “Traditional IT architectures use a server infrastructure, that requires managing the systems and services required for an application to function,” he says. It doesn’t matter if the servers happen to be on-premises or cloud-based. “The application must always be running, and the organization must spin up other instances of the application to handle more load which tends to be resource-intensive.”
Serverless architecture goes much deeper than traditional cloud arrangements, which are still modeled on the serverful model. Serverless, Feghali says, is more granular, “focusing instead on having the infrastructure provided by a third party, with the organization only providing the code for the applications broken down into functions that are hosted by the third party. This allows the application to scale based on function usage. It’s more cost-effective since the third-party charges for how often the application uses the function, instead of having the application running all the time.”
How should the existing or legacy architecture be phased out? Is it an instant cut over, or should it be a more gradual migration? Feghali urges a gradual migration, paying close attention to security requirements. “There are specific use cases that will still require existing legacy architecture,” and serverless computing “is constrained by performance requirements, resource limits, and security concerns,” Feghali points out. The advantage serverless offers is that it “excels at reducing costs for compute. That being said, where feasible, one should gradually migrate over to serverless infrastructure to make sure it can handle the application requirements before phasing out the legacy infrastructure.”
Importantly, a serverless architecture calls for looking at security in new ways, says Feghali, “With the new service or solution, security frameworks need to be evaluated to see what new gaps and risks will present themselves. They will then need to reassess their controls and processes to refine them to address these new risk models.”
Security protocols and processes differ in a serverless environment. Namely, with the use of serverless computing, an enterprise’s attack surface widens. “The attack surface is much larger as attackers can leverage every component of the application as an entry point,” Feghali says, which includes “the application layer, code, dependencies, configurations and any cloud resources their application requires to run properly. There is no OS to worry about securing, but there is no way to install endpoint or network-level detection solutions such as antivirus or [intrusion protection or prevention systems[. This lack of visibility allows attackers to remain undetected as they leverage vulnerable functions for their attacks, whether to steal data or compromise certificates, keys, and credentials to access the organization.”
At this point, introducing the security measures needed to better protect serverless environments may add more cost and overhead, according to a study out of the University of California at Berkeley, led by Eric Jonas. “Serverless computing reshuffles security responsibilities, shifting many of them from the cloud user to the cloud provider without fundamentally changing them,” their report states. “However, serverless computing must also grapple with the risks inherent in both application disaggregation multi-tenant resource sharing.”
One approach to securing serverless is “oblivious algorithms,” the UC Berkeley team continues. “The tendency to decompose serverless applications into many small functions exacerbates this security exposure. While the primary security concern is from external attackers, the network patterns can be protected from employees by adopting oblivious algorithms. Unfortunately, these tend to have high overhead.”
Physical isolation of serverless resources and functions is another approach — but this, of course, comes with premium pricing from cloud providers. Jonas and his team also see possibilities with generating very rapid instances of serverless functions. “The challenge in providing function-level sandboxing is to maintain a short startup time without caching the execution environments in a way that shares state between repeated function invocations. One possibility would be to locally snapshot the instances so that each function can start from clean state.”
Feghali’s firm, Attivio Networks, focuses on adoption of “deception technologies” intended to provide greater visibility across the various components in a serverless stack, “as a way to understand when security controls are not working as they should, detect attacks that have by-passed them, and for notification of policy violations by insiders, suppliers, or external threat actors.”
The bottom line is handing over the keys of the server stack to a third-party cloud provider doesn’t mean outsourcing security as well. Security needs to remain the enterprise customer’s responsibility, because it is they who will need to answer in the event of a breach.