Plan your journey towards a secure serverless future in three simple steps

Think AWS Lambda, Azure Functions and Google Cloud Functions for example. The rise of on-demand models for microservices applications, data-processing, mobile and IoT services makes FaaS an attractive option over Platform-as-a-Service (PaaS) as charges are incurred on execution time of the function (event-driven computing if you like) rather than the running time of the application thread itself. A self-scaling cloud architecture that is both pay-per-use and moves the development focus away from server infrastructure and onto business logic seems like a no-brainer. 

Until, that is, someone goes and mentions security. That someone is going to be me I'm afraid. 

So, is serverless also insecure? The honest answer is that it isn’t, or at least it doesn’t have to be. Unfortunately, courtesy of being a relatively immature ecosystem with users all too often not fully aware of the security implications, the reality is that insecurities tend to come to the fore. Certainly, serverless does change the security proposition. On the security-positive side of the equation, serverless brings wins such as less running time which means there will be less time for the bad guys to do stuff they shouldn’t be, and by defining least-privilege roles for each function the available options for attack escalation can be reduced. That there’s no need to worry about OS patch management, a perennial security headache, is another positive as this now becomes the responsibility of the platform provider. However, we must go back to that immaturity factor as it is here that the insecurity risks start to emerge. Once documentation improves, along with the evolution of both an accepted best-practice route to better security and better tooling with which to get there, the risk will be mitigated if not entirely eradicated of course. For now, though, it’s imperative to appreciate the potential security weaknesses of a serverless approach so you can address them in your FaaS implementations: make sure these three are top of your list.

1. Attack surface on the rise

The very nature of a serverless, FaaS, approach means that applications will be split into small functions which effectively increases the number of assets that need protecting. Throw into the equation the fact that these functions obviously need to communicate with, and are triggered by, different sources and you are increasing the potential attack surface as a result. So, while it can rightly be said that the distributed basis of serverless architectures is one of the big selling points, it is also raising a security red flag by providing a greater number of attack opportunities for the threat actor. Think about it logically and you see how functions that are assuming that a previously executed function (or input) can be trusted cannot be secure. The threat actor may look to invoke a function directly or compromise an existing one, so it’s imperative to treat each function as if it were a standalone object and protect it accordingly. Input validation is your friend here, you should not trust inputs coming from the exterior and interior as well.Shared libraries are your friend here.

2. Dependencies watch out 

Shared libraries are also a security weakness if not properly secured themselves. Because each function will have its own dependencies, and because more functions means more dependencies, this equates to more risk. Reusing libraries are the most obvious risk-factor here., especially if you are following the advice given to reduce the attack surface. Open source libraries are the most commonly used, unsurprisingly so given the ease of use and low impact on development budgets. Indeed, it’s not uncommon to find that within any given deployed function the libraries used comprise most of the actual code. You can see where this is heading, I hope? Yep, the vulnerability risk posed by libraries needs to be properly managed as threat actors understand they offer a soft entry point. This can be mitigated with relative ease if you remediate fix the known vulnerabilities, which requires a process of constant assessment. monitoring.

3. Visibility needed

Ah yes, monitoring. This really should be writ large in flashing LEDs on every DevOps monitor screen, and writ even larger in a serverless environment. Why so? Simply because it brings with it less visibility. Often there will be no access to logs at the infrastructure level, and even if the serverless architecture vendor does provide logging functionality there is every chance that the default configuration won’t properly address your security needs. Indeed, that default configurations are never going to be secure enough is a message that cannot be overstated across the entire serverless ecosystem. But the bottom line here is that you must have adequate visibility of your applications and that means real-time logging built into the applications themselves. Unless there is automated logging and monitoring of events and functions, you will always be chasing your tail when it comes to detecting threat actor activity and preventing compromises. All that said, this process must be properly configured to avoid logging sensitive data for one thing and logging too much for another. Verbose error log messages can introduce risk as much as overly succinct ones, too much information (especially false alarms) will tie up resources that could be dealing with a real security event that’s further down the queue.

I'm not into knocking serverless, I think it's a truly revolutionary shift in the way applications are delivered. What I am into is ensuring that security strategies are evolutionary and so able to respond to that fact that while serverless reinforces some aspects of the application threatscape it brings new focus to others. You can bet your bottom dollar that the bad guys are already homed in on serverless apps as a new threat opportunity, so you need to be equally focused on keeping them out. This is, in effect, a new threatscape and one that requires new solutions. Think automation, application security testing and real-time visibility and you will be heading towards a secure serverless destination...

About the author:

Davey Winder is a veteran security journalist with three decades under his belt. The only three-time winner of the BT Security Journalist of the Year award, he was presented with the Enigma Award for a 'lifetime contribution to IT security journalism' in 2011. Currently contributing to Digital Health, Forbes, Infosecurity, PC Pro, SC Magazine and The Times (via Raconteur Special Reports) you can catch up with all his latest writings at www.happygeek.com