Serverless Security

Understanding Serverless Security and how to mitigate them

What is Serverless Computing

Serverless computing is a cloud-native development model that helps developers build and run applications and services without managing infrastructure or server-side IT. Applications in the serverless model use managed cloud services and functions as a service (FaaS) to remove the need to manage, patch, and secure infrastructure and virtual machines.

Serverless Architecture

Top 10 Security Risks and How to Mitigate Them

1. Function Event Data Injection:

• Occurs when an untrusted input is passed directly to an interpreter and gets executed or evaluated
• Multiple event sources increases the potential attack surface and introduces complexities
• E.g. Cloud storage events, Stream

2. Broken Authentication:

• Serverless apps architected in microservices-like system design often contain many distinct functions with their own purpose
• Some may expose public web APl’s, while others may serve as a proxy to different functions or processes
• E.g. Exposing Unauthenticated Entry Point via S3 Bucket with Public Access

3. Insecure Serverless Deployment Configuration:

• Serverless architecture is relatively new, the probability of misconfiguring critical configuration settings are quite high
• Make functions stateless while designing serverless architectures
• Do not expose sensitive data to any unauthorized personnel

4. Over-Privileged Function Permissions and Roles

• Follow the principle of “Least Privilege”, functions should only be given necessary privileges to perform the intended logic
• Provisioning over privileges to a function could end up being abused to perform unintended operations, such as “Executing System Functions”

5. Inadequate Function Monitoring and Logging

• To achieve adequate real-time security event monitoring with proper audit trail
• Collect real-time logs from different functions and cloud services
• Push these logs to a remote security information and event management (SIEM) system

6. Insecure 3rd Party Dependencies

• Serverless function is required to depend on 3rd party software packages, open source libraries, and consume 3rd party remote web services through API calls
• Look at 3rd party dependencies before importing their code as they could be vulnerable and can make the serverless application susceptible to cyber attacks

7. Insecure Application Secrets Storage

• Need for storing and maintaining app secrets such as :
  - API keys
  - Database credentials
  - Encryption keys
  - Sensitive configuration settings
• Encrypt environment variables and don’t store plaintext secrets (e.g. AWS Key Management Service)

8. Functions Execution Flow Manipulation

• Functions are chained; invoking a specific function may invoke another function, thus the order of invocation is critical for achieving the desired logic
• Manipulating an application’s flow will help an attacker to subvert the application logic in bypassing access controls, elevating user privileges or even cause Dos attacks

9. Denial of Service and Financial Resource Exhaustion (a.k.a Denial of Wallet)

• Define execution limits:
  - Per-execution memory allocation
  - Per-execution ephemeral disk capacity
  - Per-execution number of processes and threads
  - Maximum execution duration per function
  - Maximum payload size
  - Per-account concurrent execution limit
  - Per-function concurrent execution limit
• Use an API Management Gateway

10. Improper Exception Handling and Verbose Error Messages:

• Line-by-line debugging is more complicated and limited for serverless apps
• Verbose error messages, such as stack traces or syntax errors, expose internal logic of the serverless function, revealing potential weakness, flaws, or sensitive data
• Developers must remember to clean up

How Does Serverless Improve Security?

Here are some key points:

1. Cloud Providers Handle Operating System, Runtime Security, and Patching. When you deploy serverless applications, you essentially give up control over most of the stack to your cloud provider. This means that they take care of services like key management, and you no longer have control over things like OS hardening, admin rights, SSH, and segmentation. However, cloud providers like AWS, Microsoft, and Google are highly reliable in keeping their parts of the stack patched and secured. So, by giving them a larger portion of the stack, you can be assured that security and maintenance are taken care of on that end.
2. Stateless/Ephemeral. Serverless compute has an ephemeral and stateless nature, which makes it harder for attackers to access sensitive data. This is because serverless functions like AWS Lambda run for only a few seconds and are then terminated. Similarly, containers are recycled. Since serverless functions have no memory and come and go quickly, the risk of long-term attacks is reduced.
3. Visibility into Serverless Applications — Serverless applications are structured as a large number of small functions in the cloud, which makes security easier. Analyzing and instrumenting your packaged application takes a lot of effort for application security tools to observe or filter the internal flow of your application. With serverless architecture, these tools can be more effective at ensuring the security of your application.
4. Smaller Microservices = The Ability to Construct Suitable, Minimal Roles for Each Function. Moving to smaller microservices allows for more granular IAM implementation, enabling the application of security policies to small components and effectively reducing the attack surface.

If any function within a container requires access to read from S3, all other functions within that container will also have that privilege. However, with AWS Lambda, you can assign privileges to individual functions, and ensure that these privileges are restricted to only what is necessary. This means that if there is a vulnerability in one of your functions, an attacker will only be able to access the limited capabilities of that function, rather than the broad set of permissions that would be granted to an entire container.

What Are Serverless Security Challenges?

As serverless applications are evolving, new challenges are arising. Here are some of the major issues:

Get Rohit Jyoti’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

1. Security visibility becomes more difficult: With serverless, the number of resources and data increases considerably, making it harder to understand and manage all the information. When you have to deal with a billion events daily, it becomes challenging to obtain intelligence from the mountains of data for true observability.

2. Protocols, vectors, and attack points have multiplied: With every function comes a potential point of attack, which requires unique approaches for Google Functions, Azure Functions, and AWS Lambda security.

3. More resources mean more permissions to manage: With serverless, managing permissions for all these resources can be a challenge. Automated technology can help detect configuration risks and automatically generate least-privilege function permissions.

4. Observability into serverless apps is a challenge: Serverless apps use different services from various cloud providers, across multiple versions and regions. A comprehensive view of your entire serverless ecosystem is necessary to understand your attack surface and potential risks. As your app propagates, this security-focused view can be increasingly challenging to build and maintain.

What are Serverless Security Threats?

Serverless applications require unique security measures for effective protection against attacks, as attackers’ tactics must adapt to the new architecture.

1. The Threat of Over-Privileged Functions

Serverless applications provide the ability to apply privileges to individual functions, ensuring that such privileges are restricted to only the smallest scope necessary. This is a great opportunity to minimize your attack surface and mitigate the impact of any attack.

Unfortunately, recent research conducted by Check Point has found that a vast majority of developers are not taking advantage of this opportunity. According to our research, 98% of functions in serverless applications are at risk, and 16% of these risks are considered “serious.” Additionally, most of these functions are provisioned with more permissions than they require, which could be removed to improve the security of the function and the overall application.

Check Point assigns a risk score to each function when analyzing them. This score is based on the posture weaknesses discovered, taking into account not only the nature of the weakness, but also the context within which it occurs. After scanning tens of thousands of functions in live applications, we found that most serverless applications are not being deployed as securely as they need to be to minimize risks. The greatest security posture issues discovered by Check Point are unnecessary permissions, while the remaining issues are with vulnerable code and configurations.

2. The Groundhog Day Attack

The ephemeral and short-lived nature of serverless functions provides an added security advantage, as it becomes difficult for attackers to persist in the application for a long time. However, this does not mean that attackers will stop the attacks, but instead, they may change their strategy. Since serverless functions have a short duration, security threats may take on a different form. Attackers may launch a shorter attack that steals a few credit card numbers, and then repeats this attack in a continuous loop, which is known as a “Groundhog Day” attack.

3. Poisoning the Well

Attackers can still gain long-term persistence in your cloud-native resources despite their short lifespans. One way they do this is through an upstream attack, commonly known as “Poisoning the Well”.

Cloud-native applications are made up of numerous modules and libraries that contain code from different third-party sources. Attackers exploit this by introducing malicious code into common projects. Once they have successfully poisoned the well, the malicious code can call home from your cloud apps, receive instructions and wreak havoc.

4. Increased Time for Serverless Security Configuration

While it may not be considered a security “threat,” securing a serverless architecture can be a challenge and a potential obstacle. One of the advantages of serverless computing is that it allows for faster application development. However, the traditional approach to security, where developers write code and security operations put security controls around those workloads, does not work well for serverless environments. If developers have to wait for security to open ports, IAM roles, or security groups for them, the benefit of increased velocity is lost. Removing security operations from the equation is not a solution as it can be a risk.
On the other hand, setting up permissions for the many serverless resources and interactions between them is a time-consuming task. Spending developers’ time on security configuration can quickly become expensive and is not the best use of their time. One solution is to employ automation, such as the CloudGuard Platform, to increase serverless security without consuming excessive amounts of developer time.

5. Increased Time for Security Processing

Serverless computing has the advantage of allowing you to pay only for what you consume, which can help reduce your costs. However, this also means that any increase in processing time will result in an increase in costs. It’s important to note that adding excessive app security configuration can make your functions work harder, leading to an increase in costs. While investing in security is essential, it’s crucial to implement it properly to avoid unnecessary cost increases. This is similar to the challenge of increased time for serverless security configuration, which is not a threat but a challenge that you need to address while securing your serverless architecture.

Serverless Security for Enterprise

Benefits of Serverless Architecture

According to O’Reilly, by 2020, 40% of organizations had fully adopted serverless architecture. Since then, serverless has become a dominant application execution environment, with further growth on the horizon, as per The State of Cloud Native Security Report 2023, which shows that 70% of survey respondents reported planned use increases in the next 24 months.

Adopting a serverless model has several benefits for application development, including reduced operational overhead, increased agility, and reduced costs. With no servers to manage, developers and DevOps don’t have to worry about scaling infrastructure, installing and maintaining agents, or other infrastructure-related operations. 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. 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.

Figure 1: Components of the severless model

Serverless Applications Require Serverless Security

Every time there is a major innovation in software development and IT operations, there is a change in attack vectors and security risks. In the past, security professionals had to adapt to new ways of hardening, defending and governing their infrastructure as technology advanced from virtualization to containers. The introduction of serverless applications presents one of the most significant paradigm shifts in application security ever seen.

Traditionally, organizations relied on infrastructure and network-based tools to protect their applications. They would use firewalls to inspect traffic, intrusion detection systems to detect malicious activity or runtime application self-protection (RASP) technology to protect applications. Even with containers, organizations could still rely on the security of the underlying infrastructure to some extent.

In a serverless application, distributed cloud services work together, such as an S3 bucket triggering a Lambda Function, which in turn triggers DynamoDB®. In this architecture, there is no space for firewalls, IDS/IPS tools, or any kind of instrumentation agents or server-based protection methods. Instead of relying on network inspection and access control lists, the serverless model shifts the focus of security to IAM permissions, behavioral protection, and strong code.

Figure 2: Application in serverless model

Serverless Attack Vectors

Adopting serverless security allows applications to have a strong security foundation since organizations no longer need to be concerned about infrastructure, network, or host security. However, new attack vectors have emerged, and familiar attacks have been adapted for serverless environments. For a complete list of potential risks, 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, though, 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.

Event data injection 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. The 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 aren’t as well understood as web environments where developers know which message parts shouldn’t be trusted (e.g., GET/POST parameters, HTTP headers, etc.).

Figure 3: Event data injection attack surface

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.

Researched and compiled by: Vishwakarma Institute Of Technology

Authors: Jiyan Patil, Rohit Jyoti, Omkar Kanase, Mayur Khadde