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.
THINGS THAT GOT BETTER
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.
Cloud Providers Handle OS & Runtime Security & Patching
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.
Smaller Microservices = Fine-Grained IAM
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.
Stateless/Ephemeral == No Long-Term Resident Injections
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.
More Visibility into App Behavior
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.
THINGS THAT GOT WORSE
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:
Security Visibility Got Harder
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.
Many More Points of Attacks, Protocols & Vectors
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.
Erosion of The Perimeter as We Used to See It
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?
More Resources = More Permissions to Manage
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.
Where Do You Deploy Security?
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.
THINGS THAT CHANGED
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
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.
Cloud Security Is Mostly AppSec
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.
Additional Serverless Security Resources
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.”
*** This is a Security Bloggers Network syndicated blog from Blog – Protego authored by Hillel Solow. Read the original post at: https://www.protego.io/serverless-security-scorecard/