
Serverless Security: What's Left to Protect? - tkadlec
https://www.infoq.com/articles/serverless-security
======
nzoschke
> However, managing granular permissions for hundreds or thousands of
> functions is very hard to do.

When building a FaaS app from scratch granular permissions are manageable.
Functions are small, so it’s easy to reason about the capabilities they need
and write tight policies.

I don’t see why this doesn’t scale to a larger FaaS app.

I think the real trick is to avoid the bundling of functions and policies the
article suggests people do out of convenience.

I’m working on a practical guide to Lambda and IAM policies here:

[https://github.com/nzoschke/gofaas/blob/master/docs/per-
func...](https://github.com/nzoschke/gofaas/blob/master/docs/per-function-
policies.md)

~~~
guypod
It's entirely doable to manage permissions granularly, but it's not the most
natural thing to do. It's FAR easier to broaden permissions.

The more functions you have and the more time they've had to morph, the more
likely they are to have far greater permissions than they should.

------
michaelbuckbee
Admin'ing a system is hard work requiring a deep understanding of many
different application, os and network systems, rigorous attention to detail,
good communication skills and being subscribed to a variety of fractured news
and alert systems to sort out what inbound patches and mitigations are
relevant and what can/should be applied.

Which leads me to the point of FAAS (and other managed services like Heroku,
etc). which is to let you put up a web service on the increasingly hostile and
dangerous Internet without either:

\- Learning all of the above (none of which is taught in a standard CS degree)

\- Hiring a Sysadmin for six figures.

Any time FAAS comes up people correctly point out that a sysadmin still needs
to do the work of handling the underlying OS updates, etc - which misses the
point. It's the difference between flying in a 737 that's been inspected by a
certified mechanic who is looking for a hundred things it would never occur
for me to even consider and flown by a pilot with thousands of hours in the
cockpit versus someone who flies their small aircraft a couple weekends a
month and does their own inspections.

In general, I trust that the security and SRE teams at Google, AWS, Microsoft
who are the main people deploying building out these FAAS systems have a
better handle on these things than whoever is handling sysadmin tasks on
random VPS.

~~~
guypod
I have no doubt the operators of those networks do - on average - a far better
job operating the systems. My concern is that FaaS developers would therefore
consider FaaS naturally secure, and forget there are still quite a few
security risks they have to tackle themselves.

------
pdpi
OS and server stack updates aren’t a case of “more secure”. Somebody still
needs to do that work, and you’re trading the responsibility of doing it for
the promise that somebody else will (often with no visibility into how and
when).

DoS is only “solved” by “infinite capacity” insofar as you’re willing to pay
for the capacity. If you have any spending caps in place, you’ll be DoSed by
burning through your budget. DoS protecting must happen at a lower level than
that.

~~~
guypod
The fact OS patching is done by people whose entire job and profession is to
keep systems patched matters - they are patched more often and faster. In
addition, the fact servers don't live long means it's easier to patch servers
(since there's no need to patch a running system). So there's a very real
difference here.

------
nimbius
as a system administrator, I find the summary as laughable as the FAAS
movement itself.

"FaaS takes on the responsibility for “patching” the underlying servers,
freeing you from OS patching"

So a sysadm-er, devops admin will be rolling these out and back with CI on a
regular basis to dev,test and prod.

"Denial of Service (DoS) attacks are naturally thwarted by the (presumed)
infinite capacity Serverless offers."

Unless youre invoicing department is cutting cheques to cloudflare, you'd be
surprised just how limited the service is. Capacity might be amorphously
defined as infinite on paper, but network capacity is quite real.

"Since the OS is unreachable, attackers will shift their attention to the
areas that remain exposed – and first amongst those would be the application
itself."

the OS is reachable, what you mean to say is that its not your problem.

~~~
guypod
\- A sys admin will _not_ be rolling out OS patches. The platform does itself.
\- Attackers typically use DoS to make a system unavailable, not just make it
expensive to operate. I do note the cost concern, but if attackers are
unsuccessful taking a system down, they are less likely to attack it. \- I
indeed meant "attacking through the OS is unreachable", referring to the
portion explaining the OS patches are better managed. It's indeed not
perfectly accurate phrasing, but allow a guy some literal freedom in the
summary - the details came before.

~~~
kayfox
Some attackers are perfectly fine with costing a company a ton of money
without taking their service down.

------
clwg
I don't necessarily agree with serverless thwarting DoS attacks. While
technically it makes it easy to scale to accommodate the increase load (in the
same way that auto-scaling will). The denial of a service is the result of
your inability to pay for that "infinite" scalability.

Personally I'd much rather have to deal with my service being offline for the
duration of a DoS attack, then have my company go broke from having to pay for
the capacity allocated to servicing the attack.

~~~
guypod
Fair point. I see the _security_ concern, as far as availability goes, as
something FaaS improves, but it's definitely up to you to decide whether
downtime is better or worse than a big bill.

------
0xFFFF0000
Most likely way an APT compromises your service is via an infrastructure
attack - e.g. having your service hacked via a phishing attack and then the
APT pivots through the environment until they find the mighty AWS accounts.
Server-less doesn't change that.

------
TurningCanadian
"Known vulnerabilities in application libraries are just as risky as those in
the server dependencies, and the responsibility for addressing vulnerable app
libraries falls to you – the function developer."

This isn't any different from the non-FASS world, but it is a good reminder
that you still need someone doing regular maintenance.

------
originalsimba
"Since the OS is unreachable"

Woah slow down there what? That's a significant presumption.

This 'serverless' thing is a fad.

~~~
pmlnr
"Since the OS is unreachable": "ideally and theoretically, the OS is behind
layers of opaque abstraction and we hope nobody will find security holes to
directly access it"

------
t3h2mas
Related CCC talk
[https://media.ccc.de/v/33c3-7865-gone_in_60_milliseconds](https://media.ccc.de/v/33c3-7865-gone_in_60_milliseconds)

