What is Serverless? How Does it Impact Security?

Written by the Serverless Working Group

What is serverless?

Serverless computing is a cloud computing execution model in which the cloud provider is responsible for allocating compute and infrastructure resources needed to serve Application Owners workloads. An Application Owner is no longer required to determine and control how many compute resources (and at what size) are allocated to serve their workload at any given time. It can rely on an abundance of compute resources that will be available to serve the workload on-demand. Therefore, Serverless computing is offered under a “Pay as you go” paradigm where payment is generally made on actual physical resources like central processing unit (CPU) usage time.

When is Serverless appropriate?

The Serverless model is most appropriate when there is a relatively large application or set of applications along with a mature software development and operations (DevOps) team, process, and products available to support them.

Serverless: A whole new security ballgame?

Cloud service providers’ introduction of Serverless services brings new security challenges to application/service developers and owners. Serverless, as an event-driven architecture, breaks workloads into a multiplicity of seamlessly isolated execution environments. Each carries a specific task and handles an individual event, running separately in time and space, with its own dependencies, code, image, privilege requirements, configuration, and lifespan. This is a significant break from the traditional security threat model and the cloud threat model in the non-serverless microservices environments. Application Owners utilizing Serverless, are required to re-evaluate the evolved threat landscape and reconsider the appropriate security controls needed.

Serverless may include flows crossing trust boundaries, such as getting data from a public location, inputting data into customer premises, calling functions in other locations, etc. The existing network boundaries fade away. This fragmentation may lead to a need to drastically increase the volume of the security raw data to be collected, processed, and analyzed in order to detect attacks.

Serverless is yet another step that immerses the workload deeper into the cloud, while moving even more functionalities that used to be owned and controlled by the workload developers, to the cloud service provider (CSP).

An example of how serverless changes security

What was previously implemented as a function-call in traditional code and potentially became a Rest API in microservices, now moves to be an event submitted, queued, and handled by the CSP. The CSP will see this through until the actual data handling is complete with a function -- sometimes, after the requester asked to have this data handed. Much control is released by the Application Owner and handed to the Service Provider -- a process that again, reframes what can and should be done by service consumers to ensure the security of the Serverless microservices/applications and by whom.

Three types of serverless threats

Threats to the Application Owner workload when using Serverless can be divided between:

1. Application owner setup phase threats
2. Application owner deployment phase threats
3. Service provider’s conduct threats

In the diagram below, we summarize key threat areas to Application Owners under Serverless.

Share responsibility for Serverless

Serverless security brings in a new paradigm of security where the Application Owner is only responsible for the protection of the application, in addition to securing the data. All aspects of managing the server or its security, including bringing up, patching the machine operating system (OS), updating, and bringing down, are managed by the Serverless platform provider, thus enabling the Application Owner to focus on the application itself instead of also focusing on the infrastructure. However, as mentioned already, Serverless introduces its own security challenges.

To better explain the shared responsibility between the Platform Provider and Application Owner for the different models, we created the diagram below.

As Function-based Serverless can be specific to an operating/ runtime environment, the platform provider takes up the responsibility of maintaining and updating different versions and programming languages.

Interested in learning more about Serverless? You can read our recommendations on How to Design a Secure Serverless Architecture.