I'm not sure, in practice, how much of a win for serverless reduced patching is, compared to say a containerized environment.
You're still likely to be deploying all the exposed components yourself (i.e. the web application and it's attendant libraries), so the attack surface and possiblity for exploitable vulnerabilities is similar.
There's a win if you're comparing to a setup where you have a load of exposed services that aren't directly related to the application (so management services like SSH) but these days I see a lot fewer of those exposed directly to the Internet from the web server hosts.
What is likely a win is lack of persistence. Attackers need to pull off attacks with limited opportunity for storing something on disk and calling it after the initial compromise, when compared to longer running services.
The thing that becomes totally critical in a serverless architecture is access control and credential management for the underlying cloud platform. Where a load of, for example AWS services are used an attacker who can get access to the console via stolen credentials can do a lot of damage, if IAM profiles haven't been managed properly.
Right. You have to authorize to some sort of management layer somewhere. In this case at the cloud API level. It's nice that it's not directly "in band" with the rest of your application code in the same physical address space, like say SSH, but you have no idea of the actual hardware isolation involved, unless you were an engineer building said cloud.
I guess what I'm trying to say is serverless just seems like a way of shifting management layers around, giving the appearance or feeling of less management. I'm not saying thats not valuable - I haven't tried it. This is just my view from the outside.
Also a big one that the author forgot to mention; because server-less back-ends are shared by many companies, there is a stronger incentive for hackers to try to hack the provider.
I'm really quite astounded that there haven't been more huge cloud hacks. I guess hypervisor authors and cloud providers have taken security seriously enough.
Probably the cloud providers don't make a lot of noise about incidents, they might even be paying off parties or providing forensic assistance on condition of NDA only. Certainly they don't seem to be publishing security advisories about vulnerabilities in their platfomrs. Looking at eg the multilayered breakins at pwn2own, these attacks should not be beyond the state of the art.
(This doesn't rule out paying a lot of attention to security, of course).
The existence of hypervisor rootkits and the vast scale of cloud provider operations argue for caution.
For example, a state-level actor can afford to train and place operatives into an AWS-scale organization with enough access to infiltrate and undermine the system.
We use bare metal hosts for the ZeroTier CAs. This is one reason, though cost/CPU is another. These machines are CPU-bound, spending most of their time signing network configs. CPU is way cheaper at OVH (bare metal) than anywhere else.
Another key aspect is new security approaches to consider during development and integration. Currently an API can be secured as desired, and everything else can be hidden behind the firewall. With the serverless approach more thought has to be given to ensure there isn't "round-a-bout" ways to bypass application security and data validation.
Edit: I don't mean to sound negative, I think serverless structure is finally the realization of what "cloud" has promised and not quite delivered for so many years.
I don't know what you are trying to say. Any complex API will have to have some custom validation code.
What we have been doing is using typescript interfaces[1] to validate our API input data. This really makes the data validation painless for us.
EDIT: Thinking about this a little more, this really only ensures that the provided data is the right "shape", there may still need to me more validation performed.
> 8. Greater flexibility leads to greater attack surface
I think this is critical. The fact that there aren't many battle-tested frameworks out there writing your own functions can introduce security bugs. But from my experience, most of the use of Serverless code are very backend, cronjob type of code, and aren't necessarily tied to any real applications. Remote execution is still possible though. I am not sure how many people out there run their website in API Gateway. I've read about one or two stories, but that's it.
Another thing is not security-related, but more with reliability. Serverless development poses challenge for performance monitoring.
Also, for penetration testers it's usually not legal or in breach of contract to try to compromise services running on cloud/serverless infrastructure because they would impact 3rd parties, starting from the cloud provider itself.
You're still likely to be deploying all the exposed components yourself (i.e. the web application and it's attendant libraries), so the attack surface and possiblity for exploitable vulnerabilities is similar.
There's a win if you're comparing to a setup where you have a load of exposed services that aren't directly related to the application (so management services like SSH) but these days I see a lot fewer of those exposed directly to the Internet from the web server hosts.
What is likely a win is lack of persistence. Attackers need to pull off attacks with limited opportunity for storing something on disk and calling it after the initial compromise, when compared to longer running services.
The thing that becomes totally critical in a serverless architecture is access control and credential management for the underlying cloud platform. Where a load of, for example AWS services are used an attacker who can get access to the console via stolen credentials can do a lot of damage, if IAM profiles haven't been managed properly.