AWS’ serverless architecture components such as S3, SQS, SNS, CloudWatch Logs, DynamoDB, Kinesis and Lambda can be tightly constrained in their operation, however it is still possible to use some of them to propagate payloads which may be used to exploit vulnerabilities in some consuming endpoints or user- generated code. This session explores techniques for enhancing the security of these services, from assessing and tightening permissions in IAM to integrating tools and mechanisms for inline and out-of-band payload analysis which are more typically applied to traditional server-based architectures. Presented by: Dave Walker, Security Solutions Architecture, Amazon Web Services Customer Guest: Wouter Neyndorff, CTO, inSided

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Dave Walker, Specialist SolutionsArchitect,
Security and Compliance
Nieuwegein 24/05/16
Securing Serverless Architectures

2. With Thanks To:

3. 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

4. Serverless Architectures:
What They Are

5. Serverless Architectures: What they Are
• “The shiny new thing”
• …thoughAmazon 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”

6. Serverless Services

7. For Example…
Internet
Website
Activity
Indicator
Chat Service
Activity
Messages
Search
Service
Dynamo Streams
Elasticsearch
Service
Web Hosting
Twilio
Slack Chat
API Gateway
IoT
Backend Logic

8. “Caveat Emptor”?

9. “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

10. 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…

11. Control Points and Out-of-bandAttacks
• (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…

12. In-band Attacks
• There are more variables here – consider access
methods and content sizes:

13. Constraining Access and
Permissions

14. 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)

15. 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

16. Wrapping Lambda Functions

17. 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…)”

18. 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…

19. Wrapping Lambda Functions
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
API endpoint

20. Wrapping Lambda Functions
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
“Back end”
“Front end”
Our original functionTrigger event source
API endpoint

21. Wrapping Lambda Functions
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
1. Event triggers wrapper
API endpoint

22. Wrapping Lambda Functions
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
1. Event triggers wrapper
2. Wrapper passes trigger data
to analyser
API endpoint

23. Wrapping Lambda Functions
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
3. Analyser reads data
1. Event triggers wrapper
2. Wrapper passes trigger data
to analyser
API endpoint

24. Wrapping Lambda Functions
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
3. Analyser reads data
1. Event triggers wrapper
2. Wrapper passes trigger data
to analyser
4. Wrapper invokes Function
API endpoint

25. Wrapping Lambda Functions
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
5. Function readsdata and processes as normal
3. Analyser reads data
1. Event triggers wrapper
2. Wrapper passes trigger data
to analyser
4. Wrapper invokes Function
API endpoint

26. Wrapping Lambda Functions
• 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 J )
• 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

27. Wrapping Lambda Functions
• 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

28. Wrapping Lambda Functions
• 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…

29. API Gateway and API
Endpoints

30. API Gateway and API Endpoints
bucket
AWS
Lambda
AWS
Lambda
AWS
Lambda
Amazon
API
Gateway
“Back end”
API endpoint

31. 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 J
• …But we need to make API Gateway the target(s) for
calls to API Endpoints, in our main Lambda function…
• Easy!

32. 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

33. Wrapping Lambda Functions
• 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

34. Generalising Across
Serverless Functions

35. Filtering API Calls
AWS
Lambda
Amazon API
Gateway
API endpoint

36. Filtering Kinesis (and some other) Streams
AWS
Lambda
Amazon
ElastiCache
Amazon
Kinesis
Amazon
Kinesis
Amazon
DynamoDB

37. Services with Lambda Trigger Support
• Config
• CloudWatch
• S3
• DynamoDB
• Kinesis
• SNS
• SES
• Cognito
• CloudFormation

38. Conclusions

39. 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

40. 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…

41. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance

42. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
instance

43. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
long-termsecurity
credential
instance

44. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
AWS
KMS
long-termsecurity
credential
data encryption key
instance

45. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
AWS
KMS
data encryption key
long-termsecurity
credential
data encryption key
instance

46. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
AWS
KMS
data encryption key
long-termsecurity
credential
bucket
data encryption key
instance

47. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
AWS
KMS
data encryption key
long-termsecurity
credential
bucket
data encryption key
instance VPC Private Endpoint

48. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
AWS
KMS
data encryption key
role
long-termsecurity
credential
bucket
data encryption key
instance
role
VPC Private Endpoint

49. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
AWS
KMS
data encryption key
role
long-termsecurity
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

50. Extra: “Serverless” Management of Arbitrary Secrets
instances
instance
AWS
KMS
data encryption key
role
long-termsecurity
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

51. 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

52. 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/
AWSAudit Training: awsaudittraining@amazon.com

53. inSided Social Business Platform Growth & Security
AWS Summit Nieuwegein 2016
Maik Broxterman
IT Architect

54. inSided believes that brands need online
communities to help them stay relevant

55. Customers

56. Example

57. Our mission
1000 enterprise brands use an inSided community in 2025

58. How to facilitate this exponential growth?
people money product
development
customer
relations
No primary focus on infrastructure

59. AWS architecture components
EC2
EC2 Autoscaling
ELB
Route 53
Lambda
Elasticsearch
SNS
Cloudtrail
Cloudwatch logs
KMS
Cloudwatch
Config
SQS
SES
SimpleDB
Elasticache
RDS
S3
Glacier
Cloudfront
EBS

60. Challenge #1: Scalability
Traditional hardware vs AWS elasticity and autoscaling

61. Challenge #1: Scalability
Moved to AWS

62. Benefits
Past Currently Future
tickets tested
(via spot instances)
0 20/day 100’s/day
deploys ad hoc 10/day 100’s/day
scaling out days minutes instantly

63. Challenge 2: Security
Easy manual security
Customizable security
Default security
Shared security model

64. Q&A

65. www.insided.com
@insidedmedia