Serverless is a new approach to application architecture and deployment. Security becomes both easier and harder, and it is nuanced. In this post, we’ll go over the good, bad, and ugly of serverless security.
One key point that’s worth shouting from the rooftops, is that it’s not all bad. In fact, done right, your application security should improve as you move to serverless. Let’s take a look at some of the things that make your life easier.
For most of us, cloud providers will be better at handling the security of system and patching OS system and runtimes. It’s what they do for a living, and they do it well. For most of us, moving this responsibility to the cloud provider is a security plus.
If a large container executes many functions, then you have to constrain it to do a lot of things. From a security perspective, this is not ideal. Moving to smaller microservices enables you to do more fine-grained IAM around them all. You have the opportunity to apply security policies to each of those small things. This can significantly scale down your attack surface, enabling you to more easily move to least privilege.
Serverless functions run for a few seconds and then die. Containers get recycled. And the fact that serverless functions come and go and have no memory can be a security plus. You no longer have to worry about long-term attacks. Attackers are unable to get in, establish a base, and live for months stealing credit card numbers.
Of course, there are ways for attackers to consider more long-term attacks, such as upstream poisoning, stealing keys to accounts, or finding functions that may enable them to create functions or modify permissions. While long-term attacks can still occur, serverless shifts the focus away from worrying about someone living in your code for years.
In a serverless system, you’ve made things smaller and put them in the cloud. Therefore, you have more visibility in logs and monitoring tools regarding which functions interact with which, what resources are being accessed, how frequently, etc. All that visibility can help substantially with security.
There are, however, some things that are harder, either because the environment changed, or because the technologies we used to use don’t apply as well. Here are some key issues:
The total amount of info and number of resources increases with serverless. This hinders your ability to make sense of all of the data. Obtaining intelligence from the mountains of data is challenging.
If you have ten containers, you can know if they’re running or not. But when you have 1,000 functions, it’s more difficult to determine if everything is behaving the way it’s supposed to. With a billion events in your log every day, it’s difficult to know which are important.
Every function is something you must consider as a point of attack. Some are easier for attackers to access than others, but you must consider if an attacker could make each function run when they want or in a way they want.
That’s true for protocols as well. Classic web apps have a front door with a load balancer and speak HTTPS. Now you must think about numerous different event triggers, each with their own protocols and JSON structures and different ways people could trigger them.
In the past, applications had a clear boundary. The outside and inside were distinct, and we could do security at the perimeter. While it’s not ideal to have security remain exclusively at the perimeter, it was still possible to “build a wall” (And try to make the hackers pay for it…)
Serverless apps are more porous and fine-grained. It’s more difficult to discover where the perimeter lies. Each function? Each resource? The whole app?
Yes, this is advantageous because it enables more fine-grained permissions. However, instead of governing how ten containers talk to three tables and four buckets, you now have thousands of functions talking to a whole host of resources and each other. It’s challenging to determine permissions for all these interactions.
It becomes more challenging to determine where to put classic security such as WAF, firewall, and IDS. Placing them in between attackers and resources is not simple to do in serverless environments.
Finally, some things just changed. They aren’t better or worse, on balance, but they will leave us hanging if we don’t adjust to them.
Attacks and Attackers will always change whenever platforms and technologies change. Serverless is no different. The goals of the attacks haven’t changed, but how they accomplish those things may change drastically. Download our eBook, “Serverless Security Primer: Top Risks and How to Mitigate,” for further details.
Developers will deploy things more quickly and frequently. This results in challenges to configure WAFs, but also enables you to increase the velocity of security reactions.
With serverless, you only pay for what you use. Not paying for idle resources can save money. However, if a security tool will add one second to processing, you must multiply that by all your requests per month.
You have ceded control to the platform, and, to a large degree, the network is less relevant. Therefore, much of your security efforts involve securing from the application level.
Serverless, as a new application architecture, has a new and unique security landscape. The way you protect your applications must change. If you’d like to move from understanding how serverless security is different to what to do about it, download our eBook, “Serverless Security Primer: Top Risks and How to Mitigate.”