Serverless Security implications—from infra to OWASP

By its very nature, Serverless (FaaS) addresses some of today’s biggest security concerns. By eliminating infrastructure management, it pushes its security concerns to the platform provider. Unfortunately, attackers won’t simply give up, and will instead adapt to this new world. More specifically, FaaS will move attackers focus from the servers to the application concerns OWASP highlights—and defenders should adapt priorities accordingly.

This post touches on which security concerns Serverless helps, and which ones it doesn’t. Each of these bullets is probably worth of a full post of its own (which I may write later on!), but in this post I’ll keep remediation and risk management details light, in favor of covering the bigger picture.

Here’s the quick “at a glance” view of the areas of concern.

Now, let’s dive into the details!

How does Serverless help security?

Serverless moves the responsibility for server management from the application owner to the platform provider. These pesky servers are notoriously hard to secure, but the experts managing the platforms handle it quite well. Therefore, here are the three top security threats Serverless dramatically mitigates.

1. No unpatched servers, no vulnerable binaries

First and foremost, Serverless practically eliminates the main source for successful exploits today—unpatched servers. Such servers are using binaries with known vulnerabilities, as they did not apply the latest security updates of those dependencies. By most counts, dependencies with known vulnerabilities account for the vast majority of successful exploits today.

While Serverless doesn’t remove the need to keep your servers up to date, it pushes this concern to the platform provider. Managing servers is one of the core competencies, and so the likelihood machines won’t be up to date is quite low.

2. Denial of Service becomes a billing issue

Denial-of-Service attacks work by preventing a server from servicing legitimate requests, and repeating this attack until all servers that can fulfill a request become unavailable. When using FaaS, servers are provisioned on-demand and discarded (I’m overlooking platform specific performance optimizations), rendering the idea of “taking down a server” meaningless. Whenever a new request, legit or otherwise, arrives, the platform will provision a server and run the requested function.

It’s worth noting that while Serverless conceptually eliminates DoS as an availability threat, platforms do set some concurrency limits to be aware of. AWS Lambda currently defaults to capping at 600 concurrent function executions. In addition, a DoS attack can still rack up a massive usage bill, which is almost as unpleasant as a DoS attack. So don’t get too complacent about execution time or ReDoS vulnerabilities.

3. Immutability eliminates compromised servers

In many attacks, exploiting a vulnerability is merely the first step. Instead of repeating the attacks, attackers aim to compromise the server and plant a malicious agent, from which they’ll perform further and deeper attacks. The most damaging attacks, such as the breaches at Sony and Target involve such compromised servers.

In FaaS, servers are immutable and short lived, implicitly removing the possibility of a long lived compromised server. This protection does little to reduce the chance of a successful attack, but it greatly helps in reducing the post-exploit possibilities and with them the damage such an attack may bring.

Which security concerns stay the same?

As we’ve seen, Serverless takes some major threats off our hands as application owners. Does this mean attackers will simply give up on Serverless based apps? Obviously not.

Here are the three top security concerns Serverless doesn’t help. While FaaS doesn’t make these concerns worse, eliminating the previously mentioned threats naturally moves these issues up the priority list for attackers. It’s therefore more important than ever to take note of—and address—these risks.

4. Vulnerabilities in your code are still there

Serverless takes most of the “surround sound” off your hand, but what remains is your own code—including its vulnerabilities. Application level vulnerabilities (e.g. Cross-Site Scripting, SQL Injection), continue to be severe if exploited, and mitigation techniques (e.g. input validation, programmatic DB access) are as critical as ever.

Best practices here remain the same as before. Use static (SAST) and dynamic (DAST) security testing tools, make input validation easy and favor whitelisting whenever possible, etc. The OWASP Top Ten guide includes lots of great advice for this topic, as does their cheat sheet.

5. Vulnerable Application dependencies bundled in

At first glance, FaaS functions appear to be just your code—but that’s not entirely accurate. Functions also include application dependencies, pulled in from npm (Node.js), PyPI (Python), Maven (Java) or other relevant platforms. These code packages are like little pieces of infrastructure embedded inside your application.

Application dependencies are similar to the oft-exploited server dependencies. They are prevalent, downloaded billions of times a month; it’s hard to track which packages you’re using; and they are frequently vulnerable, with new vulnerabilities disclosed regularly. Attackers are already exploiting vulnerable application dependencies, but denied the easy path of vulnerable server dependencies, they will shift to attacking these similar entities in full force.

Known vulnerabilities are as easily discoverable for you as they are for attackers. Securing application dependencies requires access to a good database and automated tools to continuously prevent new vulnerable packages and get alerts on newly disclosed issues. Snyk makes this whole process super easy, and I’d encourage you to try it out! Otherwise, choose the tool that fits you and your platform best, but do not neglect this problem.

6. Data “at rest” equally accessible

Last but not least, Serverless does nothing to keep attackers away from your database. If an attacker gains access to your data through one of the vulnerabilities mentioned above, leaked credentials, a compromised insider or by any other means, FaaS will not impact it at all.

If you’re storing sensitive information, make sure you properly encrypt it. Open source crypto algorithms are broadly available, and there’s no good excuse not to use them. In addition, avoid the temptation to give everybody access to your DB (even read access!), and instead only give such access to the people and systems that need it most. FaaS allows better granularity on this front, limiting access only to the functions that directly use the DB. Lastly, do not expose your data stores directly to the internet—as we’ve seen with the latest MongoDB hack and Redis’s explicit statements, these systems were designed to be internal.

I marked this issue as “neutral”, since Serverless doesn’t hurt data security at rest. However, because functions are always stateless, in some cases state—including sensitive data stored within it—will move from a local store (e.g. file system or memory) to a network store (e.g. Redis or queues). Be sure to apply the same data security practices to such transient storage as you do to persistent storage like a DB.

Which security concerns does Serverless make worse?

Serverless doesn’t create any new security concerns, but it does amplify some of them. The architecture it drives does mean we’re doing more of certain practices, and by doing so we elevate the security concerns embedded in them. Let’s look at the top three areas where Serverless makes security more difficult.

7. Third party services & data “in transit”

Using FaaS doesn’t make you store more data, but it definitely makes you move more data around. Data that traditionally stayed on the machine is now moved between functions many times, often slightly modified between different calls. In addition, their granularity and stateless nature drives increased use of third party services, which again requires sending and receiving data on the wire.

Each time we communicate data holds a chance for the data to be leaked or tampered with. In addition, each time we communicate we implicitly trust the other party with the data we send to and receive from it, offering an opportunity for this trust to be abused. Since we communicate more in FaaS, we need to care more about this concern, and better defend against it.

Data security is a big field, but I would suggest focusing on two areas: encryption and trust. First, make sure to encrypt all data using HTTPS or keys and a KMS. Both techniques also offer some validation of the identity of the peer you’re talking to. Second, mistrust all inputs coming from a function or service you talk to, even if it’s another function. If a function implicitly trusts another function, let alone a third party service, you’ll quickly create a fragile chain that breaks down once one component becomes malicious or compromised.

8. Greater flexibility leads to greater attack surface

One of the main Serverless advantages is its flexibility, allowing us to move control flow to the client and support more use-cases without touching server side code. Unfortunately, greater flexibility means more opportunity for attackers to get your system to do unintended actions. Borrowing a quote from Mark Nunnikhoven, “Developers focus on solving a problem, security looks at what else those solutions can be used for”.

The only way to address this concern is to treat each function as its own security perimeter. It means each function needs to sanitize inputs and outputs, protect its data, and worry about securing its code and dependencies. Most systems today have a hard perimeter, but a soft inside. FaaS greatly expands this perimeter, and with it requires a broader set of defenses.

Fortunately, FaaS offers two great opportunities to apply such broad protection. First, functions are naturally smaller, making it easier (though not trivial) to better define what they can and cannot do compared to a full application, and enforce those in code and unit tests. Second, functions are typically invoked by outsiders through the API Gateway, which let you define a model or schema the call should make, offering stricter constraints on allowed inputs and outputs. Make sure to use these opportunities and secure each function on its own.

9. Security monitoring becomes extremely hard

Serverless makes it ridiculously easy to deploy code. Deploying a function to production is effectively free, and execution costs are so minimal and granular that a low-volume function will barely register in your bill. It means we have no financial incentive to not deploy a function, or to remove it once deployed. To make things worse, there’s no easy way to track who is using a function, making it very risky to remove a function once deployed, and paving the way to having thousands of rarely used functions deployed.

Reducing the deployment barrier is amazing for productivity, but creates a security nightmare. Each deployed function is a potential attack target, with potential vulnerabilities that can be used to penetrate your private networks, manipulate your database or send attacks on your behalf. Application dependencies embedded in these functions will grow stale, and new vulnerabilities will be discovered in them, making it easy to automate such exploits. Complexity in monitoring systems is the reason vulnerable dependencies are so easy to exploit and so hard to prevent.

To top that, existing security monitoring solutions don’t work in a Serverless environment. Most such solutions require an agent on the (now non-existent) long-lived server; have boot-time and run-time overhead that’s too high to be reasonable in FaaS; and cannot scale on-demand the way Serverless platforms can. In addition, these solutions are logically built around an end-to-end app, and their logic and interface are not designed for the extreme granularity of Serverless.

This challenge is an ecosystem one, and requires new approaches to come in. Make sure you track closely which functions are deployed, who uses them, and which dependencies they use. While the operational costs of running a function are low, keep in mind the total cost of ownership, including the increased risk of having unused, vulnerable or stale code in production.

Over time, we need security runtime monitoring solutions to evolve and adapt to running without agents, with low overhead and in a massively scalable fashion. We also need alternatives to infrastructure monitoring solutions that let you track vulnerable application dependencies across all functions, and help you update or remove problematic functions. Here at Snyk we’ll play our part, and are working on expanding our CI/CD solution for vulnerable app dependencies to monitor deployed functions directly—let us know if you want to be a part of the beta!

Summary

Serverless is amazing, and is revolutionizing how we operate applications. With it, Serverless brings a similar caliber seismic event to the world of security, fixing certain security concerns, elevating others, and shuffling the priorities for all the rest.In this post, I tried to capture the top three areas FaaS is better, neutral or worse for web security, compared to other cloud computing techniques. Here’s a short table summarizing them:

Since Serverless is new, we have an opportunity to make security practices and tools a natural part of how Serverless applications are built. I’m personally excited to see Serverless grow to fulfill its massive potential, both for ops and for security.