Practical Guidance for Increasing your Serverless Application's Security

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Chris Munns – Senior Developer Advocate – AWS Serverless
Practical Guidance for
Increasing your Serverless
Application’s Security

About me:
Chris Munns - munns@amazon.com, @chrismunns
• Lead Developer Advocate - Serverless
• New Yorker
• Previously:
• AWS Business Development Manager – DevOps, July ’15 - Feb ‘17
• AWS Solutions Architect Nov, 2011- Dec 2014
• Formerly on operations teams @Etsy and @Meetup
• Little time at a hedge fund, Xerox and a few other startups
• Rochester Institute of Technology: Applied Networking and Systems
Administration ’05
• Internet infrastructure geek

https://secure.flickr.com/photos/mgifford/4525333972
Why are we
here today?

What should this talk be about?
Me: “Should I have a talk about
how I think people focused on
building self managed
containerized “serverless”
platforms are missing the big
picture and its not the future”
Jefe: “No, talk about security”
Ajay Nair
Lead Product Manager –
AWS Lambda
@ajaynairthinks
Aka “jefe” to me
<Humor Slide />

What should this talk be about?
Me: “Can I do talk where I tear
apart the FUD currently in the
space showing up by people with
an odd counter productive
personal agendas?”
Product Marketing: “No, please
not that, no. Do something happy
on security.”
<Humor Slide />
Ambiguous representation
of AWS product marketing
folks sitting up front looking
concerned at me

But then...
The very wonderful Tim Wagner
(“el jefe jefe”)
and equally wonderful
Mark Nunnikhoven
delivered like 40% of my content yesterday
in their own talks...
<Humor Slide />

Serverless Dance Routine?

Photo by Klára Koszeghyova on Unsplash
Old school security
practices would
have you focused
on putting your
Lambda function
here and hoping no
one had cannons.

Photo by Paul Csogi on Unsplash
But we all
know our
Lambda
functions
live here

Today’s focus:

Anatomy of a Lambda function
Your function
code
Language
runtime
Execution
Environment
Compute
substrate

Your function
code
Language
runtime
Execution
Environment
Compute
substrate
Places where
you can
impact
security

Handler() function
Function to be executed
upon invocation
Event object
Data sent during
Lambda Function
Invocation
Context object
Methods available to
interact with runtime
information (request ID,
log group, etc.)
public String handleRequest(Book book, Context context) {
saveBook(book);
return book.getName() + " saved!";
}

Serverless applications
SERVICES (ANYTHING)EVENT SOURCE FUNCTION

Function myhandler(event, context) {
<Event handling logic> {
result = SubfunctionA()
}else {
result = SubfunctionB()
return result;
}
Function subFunctionA(thing){
## logic here
}
## logic here
}

Anatomy of a Lambda functionImport sdk
Import http-lib
Import ham-sandwich
Pre-handler-secret-getter()
Pre-handler-db-connect()
}else {
return result;
}
Function Pre-handler-secret-getter() {
}
Function Pre-handler-db-connect(){
}
## logic here
}
## logic here
}

Anatomy of a Lambda functionImport sdk
Import http-lib
Import ham-sandwich
Pre-handler-secret-getter()
Pre-handler-db-connect()
}else {
return result;
}
Function Pre-handler-secret-getter() {
}
Function Pre-handler-db-connect(){
}
## logic here
}
## logic here
}
Where you
can have a
bad time

OWASP Top 10 - 2017
• Injection
• Broken Authentication
• Sensitive Data Exposure
• XML External Entities (XXE)
• Broken Access Control
• Security Misconfiguration
• Cross-Site Scripting (XSS)
• Insecure Deserialization
• Using Components with Known Vulnerabilities
• Insufficient Logging&Monitoring

Spent 5 minutes, found all these dependency
management tools..

Bonus round: project/repo scoping
If functions share an event
source they can go in the same
repo, if not they go in their own
repo as separate “applications”
• Simplifies permissions
source but require varying
different imported packages,
make them their own function
files/jars/etc.
• Keep dependency bloat
minimized per function
Monorepo == anti-pattern for FaaS
Two rules:

Bonus round: project/repo scoping
source they can go in the same
repo, if not they go in their own
repo as separate “applications”
• Simplifies permissions
source but require varying
different imported packages,
make them their own function
files/jars/etc.
• Keep dependency bloat
minimized per function
Monorepo == anti-pattern for FaaS
Two rules:
Use language native dependency tools and put
shared logic in sub-packages

Lambda Environment Variables
• Key-value pairs that you can dynamically pass to your function
• Available via standard environment variable APIs such as process.env
for Node.js or os.environ for Python
• Can optionally be encrypted via AWS Key Management Service (KMS)
• Allows you to specify in IAM what roles have access to the keys to decrypt
the information
• Useful for creating environments per stage (i.e. dev, testing,
production)

AWS Systems Manager – Parameter Store
Centralized store to manage your
configuration data
• supports hierarchies
• plain-text or encrypted with KMS
• Can send notifications of changes
to Amazon SNS/ AWS Lambda
• Can be secured with IAM
• Calls recorded in CloudTrail
• Can be tagged
• Available via API/SDK
Useful for: centralized environment
variables, secrets control, feature
flags
from __future__ import print_function
import json
import boto3
ssm = boto3.client('ssm', 'us-east-1')
def get_parameters():
response = ssm.get_parameters(
Names=['LambdaSecureString'],WithDe
cryption=True
)
for parameter in
response['Parameters']:
return parameter['Value']
def lambda_handler(event, context):
value = get_parameters()
print("value1 = " + value)
return value # Echo back the first key
value

AWS Systems Manager – Parameter Store
Centralized store to manage your
configuration data
• supports hierarchies
• plain-text or encrypted with KMS
• Can send notifications of changes
to Amazon SNS/ AWS Lambda
• Can be secured with IAM
• Calls recorded in CloudTrail
• Can be tagged
• Available via API/SDK
Useful for: centralized environment
variables, secrets control, feature
flags
from __future__ import print_function
import json
import boto3
ssm = boto3.client('ssm', 'us-east-1')
def get_parameters():
response = ssm.get_parameters(
Names=['LambdaSecureString'],WithDe
cryption=True
)
for parameter in
response['Parameters']:
return parameter['Value']
def lambda_handler(event, context):
value = get_parameters()
print("value1 = " + value)
return value # Echo back the first key
value
#somuchawesome

“Insecure Deserialization” – Event parsing
True story: JSON parsing can be tricky
Good news: AWS services give Lambda the event payload in a defined
structure per service.
What to do:
• Explore JSON schema validation tools if processing messages
embedded in the JSON payload itself (see jsonschema npm
package as an example )
• Check data types of attributes in JSON after validation
• If processing a binary objects (say from S3): explore packages that
can help verify/test contents

Lambda permissions model
Fine grained security controls for both
execution and invocation:
Execution policies:
• Define what AWS resources/API calls can this
function access via IAM
• Used in streaming invocations
• E.g. “Lambda function A can read from
DynamoDB table users”
Function policies:
• Used for sync and async invocations
• E.g. “Actions on bucket X can invoke Lambda
function Z"
• Resource policies allow for cross account
access

"Action": "s3:*"
makes puppies cry
Photo by Matthew Henry on Unsplash

Do yourself a favor,
go read the docs..

AWS Serverless Application Model (SAM)
CloudFormation extension optimized for
serverless
New serverless resource types: functions, APIs,
and tables
Supports anything CloudFormation supports
Open specification (Apache 2.0)
- SAM Translator recently open sourced!
https://github.com/awslabs/serverless-application-model

SAM Policy Templates
MyFunction:
Type: AWS::Serverless::Function
Properties:
...
Policies:
# Give just CRUD permissions to one table
- DynamoDBCrudPolicy:
TableName: !Ref MyTable
...
MyTable:
Type: AWS::Serverless::SimpleTable

SAM Policy Templates
MyFunction:
Type: AWS::Serverless::Function
Properties:
...
Policies:
# Give just CRUD permissions to one table
- DynamoDBCrudPolicy:
TableName: !Ref MyTable
...
MyTable:
Type: AWS::Serverless::SimpleTable
36 Predefined policies
All found here:
https://bit.ly/2LM6qml

IAM + Lambda best practices
• Where/when possible try to leverage
the pre-created managed policies that
exist today
• If you are doing “service:*” be REALLY
REALLY REALLY sure that’s what you
should and need to do
• Keep tight lockdown on who/what can
invoke functions

Do I need to put my functions in an Amazon VPC?
Putting your functions inside of a
VPC provides little extra security
benefit to your AWS Lambda
functions

Do I need to put my functions in an Amazon VPC?
Should my
Lambda
function be
in a VPC?
Does my function
need to access
any specific
resources in a
VPC?
Does it also need to
access resources or
services in the
public internet?
Don’t put the
function in a
VPC
Put the
function in a
private subnet
Put the
function in a
subnet with a
NAT’d route to
the internet
Yes Yes
No No

OWASP Top 10 - 2017
• Injection
• Broken Authentication
• Sensitive Data Exposure
• XML External Entities (XXE)
• Broken Access Control
• Security Misconfiguration
• Cross-Site Scripting (XSS)
• Insecure Deserialization
• Using Components with Known Vulnerabilities
• Insufficient Logging & Monitoring

I will turn on CloudTrail, Config, and CloudTrail Data Events

aws.amazon.com/serverless

Chris Munns
munns@amazon.com
@chrismunnshttps://www.flickr.com/photos/theredproject/3302110152/

?
https://secure.flickr.com/photos/dullhunk/202872717/

Practical Guidance for Increasing your Serverless Application's Security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Practical Guidance for Increasing your Serverless Application's Security

Similar to Practical Guidance for Increasing your Serverless Application's Security (20)

Recently uploaded

Recently uploaded (20)

Practical Guidance for Increasing your Serverless Application's Security