Serverless Security And Functions-as-a-Service (FaaS)

When building a “serverless” application, have you considered the information security implications you may run into?

Serverless (not to be mistaken for FaaS, a key building block) is great when you consider the single responsibility, stateless/ephemeral concept of your code and scalable, event-driven architecture. These may warrant good, secure by design practices when you consider data in storage or during calculation. But, how about data in transit?

In a nutshell, when you use serverless, you’re mostly transferring the operational risk to the cloud – Azure/Amazon/etc. That’s even more than you would if you leased a cloud server from them. That’s true because you are now transferring all the patch management and security awareness of the underlying servers to your vendor. So what’s left for you to look after?

Well, endpoint architecture and security.

If you fail any of those, you may end up either paying excessive bills due to Internet-facing endpoints being abused, or you may even compromise the data that runs through the corresponding endpoint.

Worse yet, due to the complicated monitoring and logging, you rarely are in control of what happens where and when within your application – you only get the bill at the end of each month; but how can you detect and react to abuse?

Lastly, serverless does not guard you against the code issues that your team embeds in the application. You are still quite vulnerable to things like SQL injection, memory leaks or remote code execution. To make matters worse, serverless implicitly promotes external dependencies to 3rd party libraries. How – by shortening execution times and subsequently lowering the cost. And running 3rd party libraries is a serious issue – take, for example, the notorious npm scandals and leaks.

Looking to explore the topics in more detail? Check out this great talk by Niels Tanis during the OWASP BeNeLux Day 2018: