securing serverless architectures - aws serverless web day

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Dave Walker

Specialist Solutions Architect, Security and Compliance

23/06/16

Securing Serverless Architectures

With Thanks To:

Agenda

• Serverless Architectures: What they Are

• “Caveat Emptor”?

• Constraining Access and Permissions

• Wrapping AWS Lambda Functions

• Amazon API Gateway and AWS Service API Endpoints

• Generalising Across Serverless Functions

• Conclusions

Serverless Architectures:

What They Are

Serverless Architectures: What they Are

• “The shiny new thing”

• …though Amazon S3 has been around for 10 years, now

• “Object stores, object transmission and aggregation

pipelines, object format tranformers, standalone code

execution systems”

• Abstract (and sometimes, Container) Services

• AWS looks after the underlying OS, High Availability, Scaling,

often Application, transparently

• Often event-driven (Lambda triggers etc)

• “Customers only need to worry about their functionality”

Serverless Services

For Example…

InternetWebsite

Activity

Indicator

Chat Service

Activity

Messages

Search

Service

Dynamo Streams

Elasticsearch

Service

Web HostingTwilio

Slack Chat

API Gateway

IoT

Backend Logic

“Caveat Emptor”?

“Everything Starts with a Threat Model”

• STRIDE, DREAD, others

• Identify:

• Actors

• Vectors

• “Bad stuff that could happen, when bad people get creative”

• Probabilities and consequences of bad stuff happening

• Apply technical and procedural mitigations

• …all the way up the OSI stack, from Network to Application

Attack Vectors

• Application-level and API-level attacks

• “If it takes input, it likely has an in-band attack vector”

• “If it has a control point, it likely has an out-of-band attack

vector”

• “Even if it doesn’t itself have a useful compromise, it might be

a useful propagation vector”

• A successful attack = disruption or corruption of service

output, or reduction in responsiveness to future service

calls, or being a conduit of “bad content” to vulnerable

consumers of the service.

• Consider the OWASP Top 10 and other application-level

attacks…

Control Points and Out-of-band Attacks

• (Almost) everything in our list has an API Endpoint.

• API Endpoints are exposed to the Internet over https, using

TLS 1.2 and unidirectional trust via s2n

• API Endpoints are scaled, rate-managed and connection-

monitored

• API Endpoint calls need Sigv4

• SHA256 HMAC with Secret Access Key (240-bit entropic) over

REST request

• REST calls are checked for formation correctness

• Looking pretty well-covered…

In-band Attacks

• There are more variables here – consider access

methods and content sizes:

Constraining Access and

Permissions

IAM is your First Port of Call

• Quickest and highly effective way to reduce risk of

serverless “misbehaviour” at sub-data level

• All API access should be Role-based

• Roles can be given to EC2 Instances and Lambda functions

• Roles use ephemeral STS tokens rather than static keys

• Reduces consequences of static key mishandling, no motivation

to hard-wire into code

• Cross-account access gets close to Mandatory Access

Control

• See video of presentation from UK Security Roadshow

(Coming Soon)

IAM is your First Port of Call

• API calls can be constrained in IAM by Source IP

address

• Get the AWS range from https://ip-

ranges.amazonaws.com/ip-ranges.json

• We could use this to ensure that only our wrapper functions

can call our main Lambda functions or the real API endpoints

• Recent development: verify when permissions were last

used

• See

https://blogs.aws.amazon.com/security/post/Tx280RX2WH6

WUD7/Remove-Unnecessary-Permissions-in-Your-IAM-

Policies-by-Using-Service-Last-Access

https://ip-ranges.amazonaws.com/ip-ranges.json

https://blogs.aws.amazon.com/security/post/Tx280RX2WH6WUD7/Remove-Unnecessary-Permissions-in-Your-IAM-Policies-by-Using-Service-Last-Access

Wrapping Lambda Functions

Let’s start with Lambda…

• Why?

• It’s a great test case, as:

• It can take input from (almost) anywhere

• It can do (almost) anything with that input, given appropriate

permissions

• It can output (almost) anything to (almost) anywhere

• Customers have control over what happens between input and

output

• Risk: “you can write insecure code in any language (including

Node.js, Java, Python and anything you can call from them…)”

Let’s start with Lambda…

• Already good info on developing Lambda functions -

https://aws.amazon.com/blogs/compute/continuous-

integration-deployment-for-aws-lambda-functions-with-

jenkins-and-grunt-part-1/ ,

https://aws.amazon.com/blogs/compute/continuous-

integration-deployment-for-aws-lambda-functions-with-

jenkins-and-grunt-part-2/

• Lambda functions run in an IAM role

• Consider cross-account function calls (see

https://aws.amazon.com/blogs/compute/easy-authorization-

of-aws-lambda-functions/ )

• Now let’s add a front-end wrapper / filter and back-end / side

API checker…

https://aws.amazon.com/blogs/compute/continuous-integration-deployment-for-aws-lambda-functions-with-jenkins-and-grunt-part-1/

https://aws.amazon.com/blogs/compute/continuous-integration-deployment-for-aws-lambda-functions-with-jenkins-and-grunt-part-2/

https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/


bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway

API endpoint


bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway

“Back end”

“Front end”

Our original functionTrigger event source

API endpoint


bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway

1. Event triggers wrapper

API endpoint


bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway


2. Wrapper passes trigger data

to analyser

API endpoint


bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway

3. Analyser reads data



to analyser

API endpoint


bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway




to analyser

4. Wrapper invokes FunctionAPI endpoint


bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway

5. Function reads data and processes as normal




to analyser

4. Wrapper invokes FunctionAPI endpoint


• First function, configured to trigger on the Lambda event,

is a front-end wrapper

• Passes copy of trigger event input and context to analysis

engine (hello, Alert Logic )

• Optionally, waits for “content OK” response from analysis

engine (in-band checking) to determine whether main

Lambda function should be invoked

• …or calls main Lambda function immediately, if performance

is more critical (out-of-band checking)

• Has the same IAM Read / Get permissions in its role as the

main Lambda function, plus what’s needed to send trigger

info and invoke the main Lambda function


• Analysis Engine

• Needs IAM permissions to be able to read from the trigger

source

• Needs to be configurable to respond to the calling Lambda

function after checks are complete (in-band checking, IPS-

style) and / or raise alerts – eg via SNS – if “badness” is

found (out-of-band checking, IDS-style)

• In discussion with Alert Logic (co-inventors), but concept and

invocation mechanisms are non-exclusive


• Second function, invoked by the first, is our main

Lambda function

• Modify the permission conditions in the IAM role so that this

function can only be called from IP addresses in the

AMAZON range in the same Region

• ie our wrapping Lambda function

• Consider passing and verifying a shared secret

• With the front-end wrapped, now let’s look at the back…

API Gateway and API

Endpoints

API Gateway and API Endpoints

bucketAWS

Lambda

AWS

Lambda

AWS

Lambda

Amazon

API

Gateway

“Back end”

API endpoint

API Gateway and API Endpoints

• Consider API Gateway as a protective front-end onto the

main AWS API Endpoints

• Can rate-limit calling frequency

• Can have back-end Lambda functions on each of REST GET,

PUT, POST, PATCH, DELETE, HEAD, OPTIONS to check

call content

• Supports Sigv4 – and generates logs

• So, we have a back-end wrapper function

• …But we need to make API Gateway the target(s) for

calls to API Endpoints, in our main Lambda function…

• Easy!

Endpoint mappings in boto and Java SDK:

{

"autoscaling": {

"ap-northeast-1": "autoscaling.ap-northeast-1.amazonaws.com",

"ap-northeast-2": "autoscaling.ap-northeast-2.amazonaws.com",

"ap-southeast-1": "autoscaling.ap-southeast-1.amazonaws.com",

"ap-southeast-2": "autoscaling.ap-southeast-2.amazonaws.com",

"cn-north-1": "autoscaling.cn-north-1.amazonaws.com.cn",

"eu-central-1": "autoscaling.eu-central-1.amazonaws.com",

"eu-west-1": "autoscaling.eu-west-1.amazonaws.com",

"sa-east-1": "autoscaling.sa-east-1.amazonaws.com",

"us-east-1": "autoscaling.us-east-1.amazonaws.com",

"us-gov-west-1": "autoscaling.us-gov-west-1.amazonaws.com",

"us-west-1": "autoscaling.us-west-1.amazonaws.com",

"us-west-2": "autoscaling.us-west-2.amazonaws.com"

},

• boto/boto/endpoints.json and aws-java-sdk-

core/src/main/resources/com/amazonaws/partitions/end

points.json


• Hack the in-environment SDK for your own main

Lambda function!

• 2-stage function needed, in the execution context:

• 1. Verify that the endpoints as defined in the SDK are your

own API Gateway endpoints; set them if not

• 2. Invoke the actual “doing stuff” function

Generalising Across

Serverless Functions

Filtering API Calls

AWS

Lambda

Amazon API

GatewayAPI endpoint

Filtering Kinesis (and some other) Streams

AWS

Lambda

Amazon

ElastiCache

Amazon

KinesisAmazon

KinesisAmazon

DynamoDB

Offloading Encryption in Transit

Amazon

API

Gateway

AWS

KMS

data

encryption key

AWS

Lambda

role

API Endpoints

Amazon

SQS

instance

Amazon

Kinesisrole

Services with Lambda Trigger Support

• Config

• CloudWatch

• S3

• DynamoDB

• Kinesis

• SNS

• SES

• Cognito

• CloudFormation

Conclusions

Threats and Mitigations

• IAM is your first port of call, for limiting API calls and their

scope

• Cross-account access can also be useful here

• API Endpoints are well-protected, but API Gateways can

add hooks for further protection at Layer 7 to any service

• …though they’re most applicable to serverless ones

• Lambda functions can provide useful tap / inspection /

filter hook points for queues and pipelines

• Lambda functions can themselves be used as wrap and

filter hook points on the input to Lambda functions

Further Food for Thought…?

• Using Serverless Capabilities to Add Security

Functionality to More Traditional Services

• Config Rules already does this

• GitHub repo at https://github.com/awslabs/aws-config-rules

• CI / CD: Add a final post-deploy Lambda step onto

CodePipeline, and API Gateway as a front-end to pentest

infrastructure, to automatically call a pentest down onto the

newly-deployed components

• Let’s discuss…

https://github.com/awslabs/aws-config-rules

Extra: “Serverless” Management of Arbitrary Secrets

instancesinstance


instancesinstance

instance


instancesinstance

long-term security

credential

instance


instancesinstance

AWS

KMS

long-term security

credential

data encryption key

instance


instancesinstance

AWS

KMS

data encryption key

long-term security

credential

data encryption key

instance


instancesinstance

AWS

KMS

data encryption key

long-term security

credential

bucket

data encryption key

instance


instancesinstance

AWS

KMS

data encryption key

long-term security

credential

bucket

data encryption key

instance VPC Private Endpoint


instancesinstance

AWS

KMS

data encryption key

role

long-term security

credential

bucket

data encryption key

instance

role

VPC Private Endpoint


instancesinstance

AWS

KMS

data encryption key

role

long-term security

credential

bucket

data encryption key

instance

role

ARN of encrypted

https key in S3 bucket

ARN of data

encryption key in KMS

Instance UserData

VPC Private Endpoint

Industry Best Practices for Securing AWS Resources

CIS Amazon Web Services Foundations

Architecture agnostic set of security

configuration best practices

provides set-by-step implementation and

assessment procedures

Helpful Resources

Compliance Enablers: https://aws.amazon.com/compliance/compliance-enablers/

Risk & Compliance Whitepaper: https://aws.amazon.com/whitepapers/overview-of-risk-and-

compliance/

Compliance Centre Website: https://aws.amazon.com/compliance

Security Centre: https://aws.amazon.com/security

Security Blog: https://blogs.aws.amazon.com/security/

AWS Audit Training: [email protected]

https://aws.amazon.com/compliance/compliance-enablers/

https://aws.amazon.com/whitepapers/overview-of-risk-and-compliance/

http://aws.amazon.com/govcloud-us

https://console.amazonaws-us-gov.com/console

https://blogs.aws.amazon.com/security/

mailto:[email protected]

Helpful Resources: New Videos

The AWS Shared Security Responsibility Model in Practice: https://youtu.be/RwUSPklR24M

IAM Recommended Practices: https://youtu.be/R-PyVnhxx-U

Encryption Options on AWS: https://youtu.be/9bn7p2tdym0

Compliance, Logging, Analysis and Alerting: https://youtu.be/42-1xpT-s6U

https://youtu.be/RwUSPklR24M

https://aws.amazon.com/whitepapers/overview-of-risk-and-compliance/

https://youtu.be/9bn7p2tdym0

https://youtu.be/42-1xpT-s6U

securing serverless architectures - aws serverless web day

Technology