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.

Serverless Security: Defence Against the Dark Arts

129 views

Published on

Recording: https://www.youtube.com/watch?v=bnXp29kQIwU
Real-world serverless podcast: https://realworldserverless.com
Learn Lambda best practices: https://lambdabestpractice.com
Blog: https://theburningmonk.com
Consulting services: https://theburningmonk.com/hire-me
Production-Ready Serverless workshop: https://productionreadyserverless.com

AWS has taken over the responsibilities of patching the OS and securing the underlying physical infrastructure that runs your serverless application, so what’s left for you to secure? Quite a bit it turns out.

The OWASP top 10 is as relevant to you as ever; DOS attacks are still a threat even if you can probably brute force your way through it as AWS auto-scales Lambda functions automatically; and did you know attackers can easily steal your AWS credentials via your application dependencies?

In addition to the traditional threats, serverless applications have more granular deployment units and therefore there are more things to configure and secure, and the tools and practices are still catching up with this fast-changing world.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Serverless Security: Defence Against the Dark Arts

  1. 1. Serverless Security defense against the dark arts
  2. 2. Shared Responsibility Model
  3. 3. Shared Responsibility Model
  4. 4. protection from OS attacks Amazon automatically apply latest patches to host VMs
  5. 5. Shared Responsibility Model
  6. 6. still have to patch your code vulnerable code, 3rd party dependencies, etc.
  7. 7. https://snyk.io/blog/owasp-top-10-breaches
  8. 8. https://snyk.io/blog/owasp-top-10-breaches Known Vulnerable Components cause 24% of the top 50 data breaches
  9. 9. https://snyk.io/blog/77-percent-of-sites-use-vulnerable-js-libraries
  10. 10. http://bit.ly/2topw5I
  11. 11. use prepared statements
  12. 12. sanitise inputs & outputs (standardise and encapsulate into shared lib)
  13. 13. security is as much about what your function should do as well as what it shouldn’t do (protect against data exfiltration)
  14. 14. http://bit.ly/2gSHtay Broken Access Control Insecure Direct Object Reference Information Leakage GraphQL Injection
  15. 15. http://bit.ly/2uKhGXF
  16. 16. Yan Cui http://theburningmonk.com @theburningmonk AWS user for 10 years
  17. 17. http://bit.ly/yubl-serverless
  18. 18. Yan Cui http://theburningmonk.com @theburningmonk Developer Advocate @
  19. 19. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant advisetraining delivery
  20. 20. theburningmonk.com/courses
  21. 21. theburningmonk.com/courses
  22. 22. realworldserverless.com
  23. 23. app dependencies is a attack surface BIGGER than you think
  24. 24. your dependencies
  25. 25. your dependencies transient dependencies
  26. 26. https://david-dm.org/request/request?view=tree
  27. 27. https://snyk.io
  28. 28. security updates are often bundled with unrelated feature and API changes
  29. 29. your security is as strong as its weakest link
  30. 30. OS Application Dependencies physical infrastructure NPM Authors Container runs in runs in runs in has hosted by published by pushes to Developers develops uses Users guardsprotects Networking runs on needs Source Code has maintains
  31. 31. OS Application Dependencies physical infrastructure NPM Authors Container runs in runs in runs in has hosted by published by pushes to Developers develops uses Users guardsprotects Networking needs runs on this is where an attacker will target in a movie Source Code has maintains
  32. 32. OS Dependencies physical infrastructure NPM Authors Container runs in runs in runs in has hosted by published by pushes to Developers develops uses Users guardsprotects Application A9 Networking runs on needs Source Code has maintains A1, A3, …
  33. 33. people are often the WEAKEST link in the security chain
  34. 34. OS Dependencies physical infrastructure NPM Authors Container runs in runs in runs in has hosted by published by pushes to Developers develops uses Users guardsprotects Application phishing… Networking runs on needs Source Code has maintains
  35. 35. OS Dependencies physical infrastructure NPM Authors Container runs in runs in runs in has hosted by published by pushes to Developers develops uses Users guardsprotects Application brute force, known account leaks, … Networking runs on needs Source Code has maintains
  36. 36. OS Dependencies physical infrastructure NPM Authors Container runs in runs in runs in has hosted by published by pushes to Developers develops uses Users guardsprotects Application brute force, known account leaks, … Networking runs on needs Source Code has maintains
  37. 37. http://bit.ly/2sFDwYX …obtained publish access to 14% of npm packages…
  38. 38. http://bit.ly/2sFDwYX debug, request, react, co, express, moment, gulp, mongoose, mysql, bower, browserify, electron, jasmine, cheerio, modernizr, redux, …
  39. 39. http://bit.ly/2sFDwYX total downloads/month of the unique packages which I got myself publish access to was 1 972 421 945, that’s 20% of the total number of d/m directly.
  40. 40. 20% of all monthly NPM downloads…
  41. 41. brute force known account leaks from other sources leaked NPM credentials (github, etc.)
  42. 42. http://bit.ly/2sFDwYX
  43. 43. http://bit.ly/2sFDwYX 662 users had password “123456” 172 — “123” 124 — “password”
  44. 44. WTF!?!?
  45. 45. oh god, that was too easy…
  46. 46. compromised package is a transient dependency sigh…
  47. 47. still “works”…
  48. 48. npmjs.com/~hacktask
  49. 49. rm -rf /!!!
  50. 50. NPM default - get latest “compatible” version, ie. 1.X.X
  51. 51. clean install (eg. on CI server) will download the latest, compromised package without any code change… NPM default - get latest “compatible” version, ie. 1.X.X
  52. 52. use `npm ci` in CI environment
  53. 53. not specific to Node.js or NPM
  54. 54. the attackers are in…
  55. 55. the attackers are in… what now?
  56. 56. Shared Responsibility Model
  57. 57. who can invoke the function?
  58. 58. what can the function access?
  59. 59. Least Privilege Principle
  60. 60. everything here is trusted
  61. 61. sensitive data
  62. 62. http://bit.ly/2zHvbcB
  63. 63. always public access is controlled via IAM
  64. 64. compromised servers allow attacker to access all of your sensitive data!
  65. 65. implement authentication and authorization for every API aka. zero-trust networking
  66. 66. Which auth method should I use?
  67. 67. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method
  68. 68. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method
  69. 69. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method
  70. 70. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method
  71. 71. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method
  72. 72. DON’T authenticate in the API function itself!
  73. 73. minimise function’s access
  74. 74. requires developer discipline
  75. 75. AWS Lambda docs Write your Lambda function code in a stateless style, and ensure there is no affinity between your code and the underlying compute infrastructure. http://amzn.to/2jzLmkb
  76. 76. S3 AWS IoT DynamoDB RDS EventStore Elasticsearch Couchbase Redshift Neo4j Google BigQuery
  77. 77. secure sensitive data both at rest and in-transit
  78. 78. leverage server-side encryption
  79. 79. http://amzn.to/1N3Twb8
  80. 80. http://amzn.to/1xF41eX
  81. 81. http://amzn.to/2tgvFR2
  82. 82. https://amzn.to/2DaXFwA
  83. 83. Least Privilege Principle
  84. 84. Disposability is a virtue
  85. 85. AWS Lambda docs Delete old Lambda functions that you are no longer using. http://amzn.to/2jzLmkb
  86. 86. easier said than done…
  87. 87. identifying component ownership in a big IT organization is challenging
  88. 88. identifying ownership of individual functions is much harder
  89. 89. tag every function with Team name
  90. 90. source: http://www.digitalattackmap.com
  91. 91. more likely to scale through DoS attacks
  92. 92. DoS + per exec billing = Denial of Wallet problem
  93. 93. configure WAF rules on API Gateway or CloudFront
  94. 94. review the default API Gateway throttling settings
  95. 95. AWS Shield Advanced also gives you access to the AWS DDoS Response Team (DRT) and protection against DDoS related spikes in your ELB, CloudFront or Route 53 charges.
  96. 96. avoid (unnecessary) long timeouts
  97. 97. alert on error rate
  98. 98. cryptojacking
  99. 99. http://bit.ly/2tlGTbc
  100. 100. monitor activities in unused regions using CloudWatch Events
  101. 101. disable inactive regions & services using AWS Organization and SCPs
  102. 102. https://github.com/OlafConijn/AwsOrganizationFormation
  103. 103. https://www.youtube.com/watch?v=mLAGHzidHJ0
  104. 104. watertight compartments that can contain water in the case of hull breach or other leaks
  105. 105. Michael Nygard
  106. 106. least privilege principle
  107. 107. per function policies
  108. 108. account level isolation
  109. 109. @theburningmonk theburningmonk.com
  110. 110. Recap
  111. 111. app dependencies is a attack surface BIGGER than you think
  112. 112. sanitise inputs and outputs
  113. 113. Least Privilege Principle
  114. 114. here’s your per function policy NEXT!
  115. 115. S3 AWS IoT DynamoDB RDS EventStore Elasticsearch Couchbase Redshift Neo4j Google BigQuery encrypt data at rest
  116. 116. S3 AWS IoT DynamoDB RDS EventStore Elasticsearch Couchbase Redshift Neo4j Google BigQuery and in-transit
  117. 117. delete unused functions.
  118. 118. DoS DoW* * Denial of Wallet
  119. 119. don’t be an unwilling bit miner
  120. 120. don’t be an unwilling bit miner safeguard your credentials…
  121. 121. prod dev compartmentalise breaches
  122. 122. people are often the WEAKEST link in the security chain
  123. 123. @theburningmonk theburningmonk.com lambdabestpractice.com
  124. 124. https://theburningmonk.com/hire-me AdviseTraining Delivery “Fundamentally, Yan has improved our team by increasing our ability to derive value from AWS and Lambda in particular.” Nick Blair Tech Lead
  125. 125. @theburningmonk theburningmonk.com github.com/theburningmonk

×