Whitepaper: Don’t think serverless security, think application security

Summary

1

As the next logical step in cloud computing, serverless is fundamentally changing the way developers need to think about applications and write code. While new technologies will always raise security questions, claims that serverless poses new risks are incorrect; there are no new cybersecurity threats that are serverless-specific. In fact, serverless can actually improve an application’s security posture. This includes advantages such as that the serverless provider handles security for major parts of the stack and a small, contained blast radius.

However, adopting serverless doesn’t mean you can forget about security. Security should already be and should always remain an integral aspect of your application. It does mean that that the ways in which teams tackle security are changing.

This whitepaper will explain why developers and cybersecurity teams should focus their efforts on protecting the application layer by:

1. Exploring and debunking FUD surrounding serverless security

2. Explaining the security considerations of serverless architectures

3. Highlighting application-layer attack vectors used to penetrate serverless applications

Don’t think serverless security, rather think application security.

Table of Contents:

Serverless Improves Security (Serverless Security FUD - Debunked)

If Serverless is So Secure, Why Do We Need New Solutions?

Protection at the Application Layer

Why Web Application Firewalls Are Not the Answer

Serverless Improves Security

Serverless has the potential to be the most secure way to run applications in the cloud. Even though serverless improves application security, developers unfamiliar with serverless often believe that it might make security level lower, more complex or even introduce new threats. Serverless doesn’t introduce new security threats, but instead makes the task of architecting and managing application’s security, much easier and much more effective.

Serverless Security FUD - Debunked

The following are security concerns commonly associated with serverless. We'll explain why they are misleading, and how serverless actually improves security as a result.

FUD Claim #1: Serverless adds new attack surfaces and increases existing attack surfacesSome claim that serverless increases the attack surface because serverless applications can be triggered from multiple sources. The truth is that there is no new attack surface in serverless architectures. In fact, it even minimizes the attack surface you control (and are responsible for) as FaaS providers are responsible for managing significant parts of the “traditional” attack surface. And application-level security stays the same.

Ben Kehoe (Cloud Robotics Research Scientist at iRobot), mentioned that: “I have yet to see a strong case for likely *serverless-specific* attack vectors. Sure, Lambda has lots of event sources, but most of these are not sources that are hooked directly to external input”. Daniel Bass, author of "Beginning Serverless Architectures with Microsoft Azure", cites the OWASP Serverless Top 10 list when stating "none of [the listed] vulnerabilities are unique to serverless at all." He concludes by saying "serverless is fundamentally more secure than most architectures that operate at a lower level of abstraction."

FUD Claim #2: Serverless security is harder to manageOne complaint that is making its way around the web is that serverless security is harder to manage because there are more individual parts (functions) compared to older architectures.

2

Serverless doesn’t introduce new security

threats, but instead makes the task of

architecting and managing application’s

security, much easier and much more effective.

3

However, serverless security is easier to manage as developers and DevSecOps teams are only responsible for maintaining the application layer, enabling them to further concentrate in greater depth on application security.

By directly managing all but the application

layer, providers can apply security practices

that better secure them and their customers.

With serverless, the provider is responsible for maintaining all of the components necessary to host applications including servers, operating systems, and backend software. By directly managing all but the application layer, providers can apply security practices that better secure them and their customers. For example, AWS Fargate and Lambda were quickly patched against the Spectre and Meltdown vulnerabilities, while other services required users to apply patches themselves.

FUD Claim #3: Serverless introduces Denial-of-Wallet (DoW) attacksOne of serverless' strengths is its ability to scale on-demand, but many believe attackers can abuse this by flooding the service with fake requests, leading to high operating costs for your organization.

While it's true that attackers can burden a serverless application with fake requests, serverless platforms often have inherent limits. AWS Lambda, for example, limits concurrent executions to 1,000 by default and can be difficult to scale past few thousand concurrents (per account). In addition, FaaS providers like AWS give users the ability to set concurrency limits on Individual Lambda functions. These cap the scale of DoW compared to other scalable architectures like PaaS or managed Kubernetes which can provide on-demand scaling of larger compute units to a higher default limit. Once these concurrency limits are reached, your application will experience as Denial-of-Service (DoS) attack, which is a troubling problem, but not specific to serverless applications.

FUD Claim #4: Serverless leads to over-privileged function (IAM) permissions and application flow manipulationAnother claim is that developers are giving functions excessive permissions, which can be abused by attackers that are able to manipulate the functions. In addition, some suggest that attackers can leverage legitimate functions activity by manipulating their invocations order.

Even if a function has permissive IAM roles, the fact that it only makes up one of many small, independent, autonomous functions in a serverless application creates a much smaller blast radius. If an attacker gains access to one function, the scope of the attack is significantly limited. In a traditional architecture with a single large application, an intrusion puts the entire application at risk.

4

As far as over-permissive roles are concerned, Chris Munns (Principal Developer Advocate - Serverless at AWS) puts it well: “developers applying EC2 roles to ec2 instances have the same decisions to make in regards to locking down IAM. the fact that you have more IAM roles doesn't change this”.

Serverless also has some additional unique benefits that can significantly improve the overall security of your application, including:

Ephemerality - Serverless functions *should* run for short amount of time. This makes attackers activity more limited, and prevents them from persistence (there is no “forgotten” server to manipulate).

Easier to spot anomalies and apply limitations - Every serverless function has a condensed and limited job. Giving sufficient control and visibility over the functions, it’s easier to spot anomalies in smaller operating units, compared to larger units like containers or VMs. It’s also easier to apply security limitations that might been complicated to apply in a different architecture.

If an attacker gains access to one function, the

scope of the attack is significantly limited.

If Serverless is So Secure,Why Do We Need New Solutions?

Although a serverless architecture offers greater security over traditional architectures, it doesn't provide complete security. Instead of balancing application and infrastructure security, teams can now focus on securing their applications without having to worry about the infrastructure. The challenge is that many existing security tools and best practices—such as WAFs (web application firewalls)—aren't as effective for serverless.

Jeremy Daly, CTO at AlertMe, explains that "[developers] need to take responsibility for the security of our applications. Traditional applications with WAFs (web application firewalls) only partially address the problem."

Serverless architectures abstract the underlying infrastructure, and affects the ability of security teams to control and monitor the application’s environment. As a result, developers and DevSecOps teams will need to address:

Limited visibilityServerless platforms provide little visibility into the underlying infrastructure, making it difficult for operations teams and system administrators to identify an attack. Without insight into systems, teams have a much harder time monitoring their applications and detecting unusual or malicious activity. Limited visibility is also mentioned as part of the OWASP Top Ten (Insufficient Logging & Monitoring). Proper monitoring and auditing is the first step towards securing your applications.

No application securityServerless providers may offer stronger platform security, but they don’t secure their customers' applications. Organizations still need to design code with security practices in mind to prevent application-specific problems such as remote code execution, weak authentication systems, and cross-site scripting (XSS). Best practices like the OWASP Top Ten Project can help organizations design hardened applications.

5

Serverless architectures abstract the

underlying infrastructure, and affects the

ability of security teams to control and monitor

the application’s environment.

Traditional tools aren’t suitable.The limited visibility and the abstraction of the infrastructure of serverless environments make traditional security solutions less effective. Host-based security, perimeter security, and runtime application self-protection (RASP) tools are suitable for traditional applications, but are either less effective for serverless applications or can't be adapted to a serverless architecture due to their integration with the application environment or host. This means that if when running VM-based/IaaS/containerized applications you relied in 3rd party security tools, then when deploying serverless applications you’ll probably end up with a lower level of security, due to the lack of suitability of traditional tools.

Sensitive workload exposure.User-facing, mission-critical, and sensitive applications require additional security due to their higher value and higher risk. In a serverless architecture, these applications may be exposed to other functions or even the public Internet. Organizations must be careful to protect these applications by applying advanced multi-layered security approach.

For these reasons, in order to achieve a high level of security, there's a need for solutions that are designed specifically for serverless applications.

6

7

Protection at the Application Layer

Visibility into your apps’ behavior at the OS level, and detailed monitoring of outbound traffic and internal networking between functions and cloud services, will allow you to gain control and achieve sufficient security understanding of your serverless applications. While there may not be visibility into every interaction between the application and the serverless platform, teams can still track data such as network traffic and service calls. Monitoring this data helps create a baseline profile for applications, making it easier to recognize unusual behaviors such as an attack and develop mechanisms to protect against them.

The second step is to define a threat model. Attackers can exploit applications in a variety of ways, and relying on serverless providers to secure the platform doesn't mean your applications are also protected. Teams need to be aware of the potential vulnerabilities in their applications in order to predict, prevent, and respond to attacks.

Attacks on serverless applications can include any common application-level attack like injections, XSS, CSRF, but also include more advanced risks such as credential theft, attackers persistence, and container poisoning. We will explain these more advanced attacks in more detail, and what they mean for DevSecOps teams:

Credential Theft

Serverless applications need access to credentials, tokens, and other forms of authentications in order to connect to other resources. These are commonly known as secrets, and the process for managing secrets can vary by serverless providers. The problem with managing secrets is that although providers will store secrets securely when not in use, functions will convert secrets to clear text while using them. This makes it possible for attackers to access secrets if they managed to manipulate the function to their favor (for example by achieving RCE).

The problem with managing secrets is that

although providers will store secrets securely

when not in use, functions will convert secrets to

clear text while using them.

Attack Persistence

An important trait of functions is ephemerality. Each invoked function is expected to run on a new environment (sandbox / container), and the environment *should* be destroyed right after the function completed its run. Creating new environments for functions, incurs cold-starts, hence many FaaS providers work around it by reusing the same sandboxes or containers for multiple invocations. While this eliminates the longer startup times associated with cold starts and can also make serverless applications feel faster, it creates a security risk. Attackers who access and modify a function can now persist attacks, whereas ideally the function would be destroyed immediately after the request. With providers optimizing away cold starts, these attackers has the ability to persist for several hours or even days.

That same persistence can also be seen as Container Poisoning - where an attacker can leverage the serverless platform scalability to run a much larger attack, or even manipulate your application’s flow for next invocations - having access to different user input or context.For example, the attacker may inject code that copies data from a database to a remote location. Instead of dumping the entire database all at once, the attacker might only copy one row of data for each function call. This method uses fewer resources and takes less time per invocation, making it much harder to detect.

For example, consider a function that requires access to a service outside AWS. The service credentials are stored in AWS Key Management Service (KMS) in an encrypted format. When the function starts, it uses the AWS SDK to copy, decrypt, and store the credentials in memory. However, an attacker uses a remote code injection attack that intercepts and returns these credentials, effectively giving them access to the service. The same scenario is relevant for a function that uses services within the AWS cloud. If attackers gain RCE capabilities or manage to leak environment data from a function, they can snatch the IAM role token from the function and use it to spread across the compromised account.

8

While this eliminates the longer startup times

associated with cold starts and can also make

serverless applications feel faster, it creates a

security risk.

A commonly proposed solution to serverless security is the use of Web Application Firewalls (WAFs). WAFs are responsible for inspecting, routing, and filtering network traffic between backend services and the public Internet. While WAFs are commonly used in cloud computing services, they have several qualities that make them less effective for serverless:

WAF security is signature-based.Advanced and zero-day attacks pass by undetected,making it effective only against known attacks.

WAFs can have a high rate of false positivesThe more threats a WAF protects against, the more likely it is to block legitimate traffic.

WAFs can't scan internal traffic.Traffic between two resources on the same serverless platform is invisible to WAFs. An attacker only needs to bypass the WAF once to launch an internal attack.

WAFs aren't designed for serverless functions.They are designed for larger applications, rather than applications made up of hundreds or thousands of lightweight, independent functions.

WAFs are expensive.For example, AWS WAF charges for each web access control list (ACL), each rule, and each request that the WAF receives, adding significant charges on top of your normal Lambda costs.

Scaling WAFs is a challenge in an environment as dynamic as a serverless architecture. WAFs must be able to adjust to sudden changes in demand, otherwise they can become the bottleneck for your application.

WAFs still offer some protections for serverless applications,but these limitations make them far from ideal.

9

Why Web Application Firewalls Are Not the Answer

Conclusion - IGNORE THE FUD!

About Nuweba

Serverless is a relatively new architecture, and some teams are afraid to adopt it due to uncertainty and perceived security risks. The serverless architecture doesn't introduce any new security threats, but actually improves the application's security. Instead of securing the entire stack, applications owners only need to protect the application layer. This might be different than securing traditional applications, as serverless changes your ability to monitor and protect certain infrastructure components, but the result is stronger security.

With the right tooling, serverless has the potential to be the most secure cloud computing architecture. The optimal solution will include dedicated application-security abilities within the serverless platform.

Nuweba rearchitected serverless from the kernel up to enable companies to use serverless for applications that require scalability, high performance, advanced application security and deep visibility in real-time. Our fast and secure FaaS platform is compatible with leading serverless platforms, so you can start using Nuweba with only one click and without any changes to your code or configuration. Unleash the full power of serverless with Nuweba.

Nuweba – Everything Serverless.

Nuweba.com

10