April 16, 2019

Three Reasons Why Threat Modelling Serverless is Different from Cloud VPC

Three Reasons Why Threat Modelling Serverless is Different from Cloud VPC

Threat modelling for Serverless deployments

Threat modelling involves decomposing an application into its constituent components. Various tools are used to assist with this but Data Flow Diagrams are especially suited to show how data moves around the system.

Special Considerations for Serverless

  • Are there special configurations such as site IDs, API keys, plugins or changes that are part of the web app entry point?
  • How do the web app, application server/layer and data stores communicate with each other? What ports are open?
  • What third party libraries, SDKs, plugins or components are part of the app?
  • Is the code in-house, third party or open source?

Looking Deeper

  • Consideration of threats against web app handler for registering HTTP routes
  • receiving the request body
  • checking required headers sanity checking incoming data and passing of data to its destination.
  • Are there external dependencies in processing such as external API calls, external libraries SDKs?

Threat Modelling answers What are we Building?

Cannot limit scope to in-house code.

Shared responsibility Model in the Cloud

Security controls provided by clouds service providers such as IAM policies, security groups, ACLs, VPC route tables which usually are treated as external entities are the absolute responsibility of the user in cloud deployment.

The shared responsibility model means that the user determines their security posture: how loose, how restrictive.

The assumption is that AWS will do as the policy states so a bad policy becomes the user’s problem or risk.

Define your trusted points and boundaries

Services such as S3, SQS, SES, API Gateway, Lambda are exposed as public APIs with some form of authentication usually required. One layer of protection whereas in an on prem datacentre multi-layer protection is normal.

Unusual Risk factors

  1. API gateway allows cross account invocations.
  2. Lambda functions can be called by anyone with IAM permissions to invoke them.
  3. S3 buckets have been notorious for being left publicly accessible with public read permissions to highly sensitive data.
    AWS has completely overhauled the S3 default to prevent public access permissions but bucket policies can be defined by a user to reverse this. The combination of user IAM policies, bucket policies and S3 object ACLs can be difficult to decipher but the S3 management dashboard clearly shows which buckets are public.
    IAM is such an important topic that I will cover it in greater depth at another time.

IAM is like putting your firewall on the internet . An authentication token is the only defence against an authorised user. No defence in depth. The best mitigation is to use different IAM profiles for different services so that an exploited token would have limited powers.
With so many interconnected services passing data in a microservice ecosystem it is important to maintain a healthy distrust of incoming data.

Reason 1. CI/CD

It is common to see accidental leakage of developer access tokens in developer scripts., Jenkins configurations, and other technical materials loaded to Github and other storage locations.

It Starts with Ownership

Identifying a resource as out of scope can lead to unintended consequences because it shuts down further investigation.
Your deployment scripts (yml Serverless files, Terraform, Cloudformation contain security group policy data i.e. your firewall, IAM policies, and are valuable assets that require security management e.g AWS Config*

How to view Cloud Entities

There is a shared responsibility between you and the cloud provider especially in matters of security


  • L List all artifacts (Bill of Materials)
  • O Overall picture , understanding of responsibility
  • S Security weak points – identify and remedy
  • S Show use a dashboard to monitor key operations

Reason 2. Everything is Public until Proven Otherwise

Every entry point whether used by external user or not needs to be considered e.g. SDK, CLI, console, other API
Threatmodeler.com has a commercial tool to conduct threat modelling analysis.

S3 is the biggest risk.

Reason 3. Do not Assume Trustable Data Origins

JSON payloads can contain anything regardless of their source
Verify content with sanity checks, event name, object key need to be validated
Data is the Infrastructure

Puresec.io a cloud security specialist have helpful articles, whitepapers and security tools
I have put a link to a document by Puresec.io to view easily :
6 Principles of a Good Serverless Solution