How Do You Protect Your Serverless Applications?

Serverless computing is increasing in popularity, but organizations must still follow best practices to secure their applications.

March 5, 2018

Jon Bartlett | Senior Security Architect | vCORE

Serverless or FaaS computing is becoming a very popular way to deploy applications, as it helps IT organizations avoid paying for unused, idle resources. Typically, these serverless applications run on AWS Lambda, Azure Functions or Google Functions and use HTTP.

At first glance, serverless computing may seem to be a more secure approach, since we no longer have to worry about patching the OS. But an analysis of the top 50 data breaches indicate that’s not always the case, according to the security experts at Snyk.

Snyk found that 12 of the top 50 breaches were caused by components with known vulnerabilities. This means that application-level vulnerabilities — including cross-site scripting, SQL injection and CSRF — are just as bad, and attackers will just move up the stack.

AWS Sr. Solutions Architect Justin Pirtle advised in a recent presentation that application security best practices (mandatory code review, static analysis, input validation/sanitization, SQLi, etc.) still apply in serverless architectures.

So, if serverless computing typically uses HTTP and application security best practices still apply, wouldn’t we protect it in a similar way to our existing IaaS, PaaS or on-premise applications? Best practices here would also remain the same for using static (SAST) and dynamic (DAST) security tools.

But what if I am using an API gateway, doesn’t that make it secure? No, a typical public cloud API gateway was not designed to address the OWASP Top 10, DDoS or detect and block bots. These types of gateways also lack virtual patching capabilities. Besides the authentication and authorization value of the API gateway, it can also restrict access via an IP address or HTTP header to your code.

Below is a simple table of API gateways. Google Cloud Functions has Google Cloud Endpoints; however, its deployment methodology is very different from AWS and Azure.

If you can restrict access via IP address and/or a HTTP header, you can easily use a WAFaaS or SaaS security engine to protect your serverless environment. You could also deploy a virtual appliance in IaaS, but that seems counter-intuitive to the benefits of an infrastructure as code strategy and creates another fragmented security tool-set.

Since serverless or FaaS computing frees us from having to patch the OS or related agents, this allows us to focus on what matters most — the application.

Further reading:

Dark Reading: Where to Find Security Holes in Serverless Architecture

ZDNet: The Top 10 Security Challenges of Serverless Architectures