Reducing the Attack Surface with Serverless Computing

Reducing the Attack Surface with Serverless Computing

Serverless environments are growing in popularity because they reduce overhead and costs. But do they necessarily improve your application’s security? Well for a start there are a lot fewer vulnerabilities to exploit. Let’s dig in and explore this a little more.

Serverless environments allow you to build applications without needing to manage and use servers. They allow you to upload your code without worrying about how to configure a server, installing the runtime environment, applying patches, setting up the networking, and identifying all the other tasks needed to run said code. Sounds too good to be true? Wait, there’s more!

Serverless environments can potentially reduce your application’s attack surface. We will compare a traditional application’s attack surface against that one running in a serverless environment.

Traditional Application’s Attack Surface

Let’s suppose you have a web application you set up on traditional servers. This application has servers dedicated to running the web application code and other servers running the database. These servers are running in the same subnet somewhere, which could be in your own facilities or in a cloud provider. The application and web servers are configured to communicate with each other.

They run the same type and version of an operating system, a specific version of a software runtime, and a particular version of the database. Now that we have established the application’s components, we can proceed to identify the attack surface. The attack surface is the accumulation of all known and unknown vulnerabilities that can be exploited. Each vulnerability can happen at all levels of the application stack. Let’s proceed to identify potential vulnerabilities:

  • An operating system has unpatched software with vulnerabilities.
  • An operating system is missing security settings (e.g., no firewall).
  • An operating system is lacking proper account management.
  • Using an operating system that is end-of-life.
  • Using a software runtime that is end-of-life.
  • Using a software runtime with known vulnerabilities.
  • Running the software runtime without account restrictions.
  • Using software libraries or packages with vulnerabilities.
  • Improperly configuring the database.
  • Giving the database full Internet connectivity.
  • And there is a lot more.

As you can see, the application attack surface can be more significant, especially when security was not a priority when building the application.

How Serverless Can Reduce The Attack Surface

Using a serverless environment can reduce the attack surface. We would only need to focus on the topmost application layer in the OSI model. But, how can serverless reduce the attack surface? Let’s look at the previously identified vulnerabilities and see how serverless can reduce or eliminate them.

  • An operating system has unpatched software with vulnerabilities. The cloud provider is responsible for patching the infrastructure and does it periodically.
  • An operating system is missing security settings (e.g., no firewall). The cloud provider is responsible for securely configuring the infrastructure with the proper security settings to protect itself.
  • An operating system is lacking proper account management. The cloud provider is responsible for setting up the proper account management for the infrastructure.
  • Using an operating system that is end-of-life. The cloud provider is responsible for ensuring it only uses currently supported operating systems.
  • Using a software runtime that is end-of-life. The cloud provider is responsible for ensuring it only uses currently supported software runtimes.
  • Using a software runtime with known vulnerabilities. The cloud provider is responsible for keeping the software runtime up-to-date.
  • Running the software runtime without account restrictions. The cloud provider is responsible for securely configuring the software run time.
  • Using software libraries or packages with vulnerabilities. The developer is responsible for auditing the software libraries and packages.
  • Improperly configuring the database. The cloud provider is responsible for securely configuring the database.
  • Giving the database full Internet connectivity. The cloud provider is responsible for securely configuring network connectivity.
  • And there is a lot more.

As you may have noticed, we offloaded our security configuration, maintenance, and risks to the cloud provider for all but one vulnerability.

Serverless is not a silver bullet or a golden gun.

Serverless comes with its own risks. The Open Web Application Security Project (OWASP) publishes the OWASP Serverless Top Ten that identifies the topmost security risks in serverless applications. Like with any application, it can be more or less vulnerable depending on the architecture, design, implementation, use, and maintenance. This post highlights how serverless can potentially reduce your application’s attack surface, especially if you do not have security expertise, time, or resources to deploy a secure application.

Before you go

About the author


Originally published on Secjuice.com

Photo by Damir Spanic on Unsplash

Did you find this article valuable?

Support Miguel A. Calles MBA by becoming a sponsor. Any amount is appreciated!