Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Securing Serverless Architecture

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

  • Login to see the comments

Securing Serverless Architecture

  1. 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. 2. With Thanks To:
  3. 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. 4. Serverless Architectures: What They Are
  5. 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. 6. Serverless Services
  7. 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. 8. “Caveat Emptor”?
  9. 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. 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. 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. 12. In-band Attacks • There are more variables here – consider access methods and content sizes:
  13. 13. Constraining Access and Permissions
  14. 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. 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. 16. Wrapping Lambda Functions
  17. 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. 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. 19. Wrapping Lambda Functions bucket AWS Lambda AWS Lambda AWS Lambda Amazon API Gateway API endpoint
  20. 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. 21. Wrapping Lambda Functions bucket AWS Lambda AWS Lambda AWS Lambda Amazon API Gateway 1. Event triggers wrapper API endpoint
  22. 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. 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. 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. 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. 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. 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. 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. 29. API Gateway and API Endpoints
  30. 30. API Gateway and API Endpoints bucket AWS Lambda AWS Lambda AWS Lambda Amazon API Gateway “Back end” API endpoint
  31. 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. 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. 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. 34. Generalising Across Serverless Functions
  35. 35. Filtering API Calls AWS Lambda Amazon API Gateway API endpoint
  36. 36. Filtering Kinesis (and some other) Streams AWS Lambda Amazon ElastiCache Amazon Kinesis Amazon Kinesis Amazon DynamoDB
  37. 37. Services with Lambda Trigger Support • Config • CloudWatch • S3 • DynamoDB • Kinesis • SNS • SES • Cognito • CloudFormation
  38. 38. Conclusions
  39. 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. 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. 41. Extra: “Serverless” Management of Arbitrary Secrets instances instance
  42. 42. Extra: “Serverless” Management of Arbitrary Secrets instances instance instance
  43. 43. Extra: “Serverless” Management of Arbitrary Secrets instances instance long-termsecurity credential instance
  44. 44. Extra: “Serverless” Management of Arbitrary Secrets instances instance AWS KMS long-termsecurity credential data encryption key instance
  45. 45. Extra: “Serverless” Management of Arbitrary Secrets instances instance AWS KMS data encryption key long-termsecurity credential data encryption key instance
  46. 46. Extra: “Serverless” Management of Arbitrary Secrets instances instance AWS KMS data encryption key long-termsecurity credential bucket data encryption key instance
  47. 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. 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. 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. 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. 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. 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. 53. inSided Social Business Platform Growth & Security AWS Summit Nieuwegein 2016 Maik Broxterman IT Architect
  54. 54. inSided believes that brands need online communities to help them stay relevant
  55. 55. Customers
  56. 56. Example
  57. 57. Our mission 1000 enterprise brands use an inSided community in 2025
  58. 58. How to facilitate this exponential growth? people money product development customer relations No primary focus on infrastructure
  59. 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. 60. Challenge #1: Scalability Traditional hardware vs AWS elasticity and autoscaling
  61. 61. Challenge #1: Scalability Moved to AWS
  62. 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. 63. Challenge 2: Security Easy manual security Customizable security Default security Shared security model
  64. 64. Q&A
  65. 65. www.insided.com @insidedmedia

×