If we go serverless what's left for us to secure?

December 9, 2018
8 minute read
security cloud

I had intended to give a resentation on this topic at ISC² Secure Summit in London in September. For private reasons this didn’t work out so I thought I’ll share my thoughts in this blog post. This is by no means an exhaustive treatment of this topic but might be useful to get you started.

All examples below are based on AWS for two reasons: they are the market leader and that’s what I know best. Microsoft (Azure functions) and Google (Cloud functions) also provide the building blocks for Serverless so the recommendations below should apply for these as well.

What is Serverless

First of all let’s briefly introduce what Serverless means. The most succint definition I came across is this definition from Simon Wardley on Twitter:

Let’s break this up a bit. In talking about Serverless you will read or hear the following acronyms a lot:

Functions are stateless and mostly event-driven while backend services allow the developer to focus on the business logic and reuse utility services. Maybe the most relevant part of all that is that it’s a code execution environment only. These functions are short-lived and the provider takes care of scaling as it is required.

If you want more details from a developer’s point of view I recommend Martin Fowler’s article Serverless Architectures.

In summary: Serverless is an architectural style not a specific technology which can be used in two flavors:

A mockup for a serverless application could look something like this:

Why does this matter?

You might think that this is just the next buzzword and hype but not really relevant. I disagree for the following reasons:

  1. Developers will love it: They have less things to care about (servers and infrastructure are somebody else’s problem). From a development prospective their biggest gains tend to come from application velocity.
  2. The CFO loves it too: Velocity is crucial for digital transformation so anything that allows for faster implementation is good. More importantly it’s a true pay for what you use model and example calculations show tremendous savings.
  3. Security folks however probably don’t love it: A traditional security approach won‘t work anymore. If we insist on the usual segregation of development and security we slow everyone down.

What changes

Standing against developers and the CFO is typically an uphill battle. Thus we better adapt and look into Serverless security specifically. It’s still the data of our company we want to protect.

We need to understand that our risks remain largely the same, but mitigations need reimagining.

Traditional security only partly applies

In traditional environments a lot of security concern is about hardening systems, watching for vulnerabilities and how to patch them, In a serverless environment we don’t even know which systems are used and the provider may swap them at any moment without us noticing. All that is no longer our job. It’s done by the Serverless cloud provider. This is in fact an additional advantage of serverless for most organisations.

A Serverless application doesn’t have a clear perimeter. Therefore typical network security approaches like firewalls and IPS systems are largely not relevant. Also most WAF systems don’t work well with Serverless.

The way Serverless applications are glued together makes static application security scanning difficult at least.

Due to the fact that functions are short-lived and not bound to a specific server traditional security monitoring of servers won’t work anymore.

Serverless creates new issues

On top of the fact that many of the things we’re used to don’t apply this architectural style creates its own issues.

From the picture above you can see that serless applications increase system complexity rather than decreasing it. The potentially huge amount of functions leads to an increase in attack surface.

Applications turn from a single monolith into a complex beast of communicating services. This means there’s a lot more data communication involved: what used to be inter-process communication within the monolith goes outside on the network.

Autoscaling and the ephemeral nature of functions makes security visibility more complex (which deviations from normal should we be worried about?).

Finally DDoS attacks can take on a totally new form: while the platform will to a large extend autoscale to address the increase in demand this also leads to steep increase in cost. DDoS becomes a “denial of wallet” attack.

What should we do to adapt

Not all is bad and dangerous here. Adapting to this new environment can in fact improve our organisation’s overall security and lead the way to a zero trust model.

I’m convinced we will only succeed if we move left and up:

I like to think about security in three dimensions: people, process and technology. All of these are relevant for securing serverless environments:


Because serverless is also about velocity we need to integrate Security into development and deployment. This requires a few changes. the most important one in my opinion to overcome requestor/approver relationships. Too many security organisations don’t work with the development teams but require them to request approvals, often late in the game.

We need to bridge this gap between Security teams and Development teams by providing security solutions during development and - if possible - work within these teams: “Show don’t tell”. This also requires to learn enough about the programming languages and frameworks developers use to be able to understand their approach and concerns.



Share on:

Using SSH Agent on Windows

November 10, 2021
2 minute read
security software

Attribution in Cyber Security

October 22, 2021
3 minute read

Adapt security to cloud-native environments

January 24, 2021
4 minute read
security cloud
comments powered by Disqus