Serverless means different things to different people, so just to align the syntax early, this post will focus on functions — such as Lambda functions, Google Cloud functions or Azure functions. Basically the functions that run on top of a cloud that manages these functions for you — along with their VM operations — out of the box.
While this post will focus on the gaps, and provide practical takeaways of what you can actually do in order to improve your serverless security posture, let’s start off with the good news: serverless has inherent security advantages and was built to implicitly manage security by design. Some examples:
- Unpatched Operating Systems. Serverless basically removes any server wrangling — patching, upgrading, and such — since serverless servers (an oxymoron of sorts) are maintained and patched for you.
- DoS Attacks. Serverless naturally elastically scales and is by design meant to handle volumes of traffic; and this is not limited to “good traffic” alone. “Bad traffic,” in an attempt to create a denial of service, also scales well on serverless. While you can still get DoSed, or a hefty bill as a result of a spike in traffic, it’s much more difficult to achieve a DoS attack with serverless.
- Long-Standing Compromised Servers. Serverless servers are inherently short-lived — meaning that if attackers want to gain access to your server, install an agent and do malicious activity, this is typically more difficult with servers that are torn down rapidly. Therefore they would need to plan a well-executed end-to-end attack in advance, which is harder and carries a higher risk of exposure.
With that said, there are still quite a few security aspects that need to be taken into account when choosing to use serverless technology. There are some good practices that you can apply to minimize these risks, which I call the CLAD Model.
#cloud services #security #serverless
