Need of Security for Serverless Architectures

Serverless architectures (also referred to as “FaaS” - Function as a Service) enable organizations to build and deploy software and services without maintaining or provisioning any physical or virtual servers. Applications built using serverless architectures are suitable for a wide range of services, and can scale elastically as cloud workloads grow while also helping developers concentrate on writing business logic without having to manage the hosting and infrastructure.

A serverless architecture can be used to solve many different problems and use cases, for example as a backend service for a Web Application. Indeed, serverless applications are becoming very popular. However, serverless has some unique security issues. In this article, we’ll explore a few security challenges from injection attacks, and discuss the best practices to resolve them.

The following image, demonstrates the shared security responsibilities model, adapted to serverless architectures:

In serverless architectures, the serverless provider is responsible for securing the data center, network, servers, operating systems and their configurations. However, application logic, code, data and application-layer configurations still need to be robust and resilient to attacks, which is the responsibility of application owners.

The comfort and elegance of serverless architectures is not without its drawbacks.

Below are the Serverless Architectures Security Top 10 List where SAS-1 indicates the most critical risk, and SAS-10 the least critical risk:

SAS-1: Function Event Data Injection

Serverless functions can consume input from each type of event source, and such event input might include different message formats, depending on the type of event and its source. In the context of serverless architectures, function event-data injections are not strictly limited to direct user input, such as input from a web API call. The various parts of these event messages can contain attacker-controlled or otherwise dangerous inputs.

SAS-2: Broken Authentication

A weak authentication implementation might enable an attacker to bypass application logic and manipulate its flow, potentially executing functions and performing actions that were not supposed to be exposed to unauthenticated users.

SAS-3: Insecure Serverless Deployment Configuration

One extremely common weakness that affects many applications that use cloud-based storage is incorrectly configured cloud storage authentication and/or authorization. Since one of the recommended best practice designs for serverless architectures is to make functions stateless, many applications built for serverless architectures rely on cloud storage infrastructure to store and persist data between executions. With insecure cloud storage configurations, sensitive confidential corporate information to unauthorized users can be exposed. 

SAS-4: Over-Privileged Function Permissions & Roles

Serverless applications should always follow the principle of "least privilege". This means that a serverless function should be given only those privileges, which are essential in order to perform its intended logic. In a system where all functions share the same set of over-privileged permissions, a vulnerability in a single function can eventually escalate into a system-wide security catastrophe.

SAS-5: Inadequate Function Monitoring and Logging

While many serverless architecture vendors provide extremely capable logging facilities, these logs in their basic/out-of-the-box configuration, are not always suitable for the purpose of providing a full security event audit trail. In order to achieve adequate real-time security event monitoring with proper audit trail, serverless developers and their DevOps teams are required to stitch together logging logic that will fit their organizational needs.

SAS-6: Insecure 3rd Party Dependencies

Oftentimes, in order to perform a single discrete task, the serverless function will be required to depend on third party software packages, open source libraries and even consume 3rd party remote web services through API calls which can become vulnerable when importing code from a vulnerable 3rd party dependency.

SAS-7: Insecure Application Secrets Storage

As applications grow in size and complexity, there is a need to store and maintain "application secrets". Storing these secrets in plain text as environmental variables is also a common mistake where environment variables can leak and reach the wrong hands.

SAS-8: Denial of Service & Financial Resource Exhaustion

While serverless architectures bring a promise of automated scalability and high availability, they do impose some limitations and issues which require attention. We have seen a dramatic increase in the frequency and volume of Denial of Service (DoS) attacks. Such attacks became one of the primary risks facing almost every company exposed to the Internet.

SAS-9: Serverless Function Execution Flow Manipulation

Manipulation of application flow may help attackers to subvert application logic. Using this technique, an attacker may sometimes bypass access controls, elevate user privileges or even mount a Denial of Service attack.

SAS-10: Improper Exception Handling and Verbose Error Messages

Some developers adopt the use of verbose error messages, enable debugging environment variables and eventually forget to clean the code when moving it to the production environment. Verbose error messages such as stack traces or syntax errors, which are exposed to end users, may reveal details about the internal logic of the serverless function, and in turn reveal potential weaknesses, flaws or even leak sensitive data.

For all Internet-facing applications, robust security is essential.

As many organizations are still exploring serverless architectures, or just making their first steps in the serverless world, we believe that securing them is critical for their success in building robust, secure, and reliable applications. We believe it is essential to scrub all HTTP/S traffic using a unified cloud-based platform that includes a next-generation WAF, DDoS protection, advanced bot management and mitigation, API security, and much more.

However, serverless architectures raise an additional question. What about events that can trigger functions directly? For example, let’s say a Lambda function is written that will process files which are uploaded to an S3 bucket. In this case, protection is not provided, and malicious user activity could result in a security compromise because the event data does not pass through the WAF for processing.

In cases like these, a small amount of effort can provide large security dividends. Although it is convenient to allow users to trigger functions when they utilize backend services, a more optimal approach is to structure functions so that user inputs always pass through the Web Application Firewall (WAF) to examine the results of all events, and defeat injection attempts.

Taking this approach offers significant leverage. A modest effort creates a large payoff—a more robust security profile.