What Is Serverless Security?
The term “serverless” generally refers to an operational model in cloud computing. In the serverless model, applications rely on managed services that abstract away the need to manage, patch, and secure infrastructure and virtual machines. Serverless applications rely on a combination of managed cloud services and function-as-a-service, or FaaS. Adopting a serverless model can impact application development in several ways:
- Reduced operational overhead: With no servers to manage, developers and DevOps don’t need to worry about scaling infrastructure, installing and maintaining agents, or other infrastructure-related operations.
- Increased agility: Since serverless applications rely heavily on managed services for things like databases and authentication, developers are free to focus on the actual business logic of the application, which will typically run on a FaaS, such as AWS® Lambda or Google Cloud Functions.
- Reduced costs: With most services used in serverless applications, the customer only pays for usage. For example, with AWS Lambda, customers pay for the executions of their functions. This typically has a significant impact on cost, as they don’t have to pay for unused capacity like they would with virtual machines.
With every major advancement in software development and IT operations comes a shift in attack vectors and security risks. In the early days of virtualization to containers, security professionals had to adapt and find new ways of hardening, defending and governing their infrastructure. The concept of a serverless application presents one of the biggest paradigm shifts ever seen when it comes to application security.
Traditionally, organizations would protect their applications by relying on infrastructure and network-based tools. They would inspect traffic with a firewall, try to detect malicious activity with an intrusion detection system, or protect applications with runtime application self-protection, or RASP, technology. Even with containers, organizations could still rely on the security of the underlying infrastructure to a certain degree.
A serverless application consists of distributed cloud services working together, such as an S3 bucket which triggers a Lambda Function, which in turn triggers DynamoDB®. In this architecture, there’s no room for firewalls, IDS/IPS tools, or any kind of instrumentation agents or server-based protection methods. Instead of focusing on network inspection and access control lists, the serverless model shifts the focus of security to permissions, behavioral protection and strong code.
Serverless Attack Vectors
Adopting serverless security gives applications a strong headstart from a security perspective since organizations no longer have to worry about infrastructure, network or host security. However, new attack vectors have emerged, and familiar attacks have been reimagined for serverless environments. Let’s take a look at one example (for the full list, refer to the Cloud Security Alliance’s “Top 12 Risks for Serverless Applications”):
Event Data Injection
Injection flaws in applications, among the most common risks to date, have been thoroughly covered in many secure coding best practice guides. At a high level, injection flaws occur when untrusted input is passed directly to an interpreter before being executed or evaluated. In the context of serverless architecture, however, function event-data injections are not strictly limited to direct user input (such as input from a web API call). Most serverless architectures provide a multitude of event sources that can trigger the execution of a serverless function.
Some event source examples include:
- Cloud storage events (e.g., AWS S3®, Azure Blob Storage, Google Cloud Storage)
- NoSQL database events (e.g., AWS DynamoDB, Azure Cosmos DB®)
- SQL database events
- Stream processing events (e.g., Amazon Kinesis®)
- Code changes and new repository code commits
- HTTP API calls
Each event input might include different message formats, and various parts of these event messages can contain attacker-controlled or otherwise dangerous inputs. This rich set of event sources increases the potential attack surface and introduces complexities when attempting to protect serverless functions against event-data injections. This is especially true because serverless architectures are not nearly as well-understood as web environments where developers know which message parts shouldn’t be trusted (e.g., GET/POST parameters, HTTP headers, etc.).
Protecting Serverless Applications
Effective serverless security focuses on ensuring code integrity, tight permissions and behavioral analysis.
- Access and permissions: Maintain least-privileged access for serverless functions and other services. For example, if an AWS Lambda function needs to access a DynamoDB table, make sure it can only perform the specific action the business logic requires.
- Vulnerability scanning: Ensure code and infrastructure-as-code template integrity by regularly scanning for vulnerable third-party dependencies, configuration errors, and over-permissive roles.
- Runtime protection: Use runtime protection to detect malicious event inputs and anomalous function behavior, and limit as necessary each function’s ability to access files, hosts, the internet and spawn child processes.