Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Serverless security: defense against the dark arts

895 vues

Publié le

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.

Publié dans : Technologie
  • Soyez le premier à commenter

Serverless security: defense against the dark arts

  1. 1. Serverless Security defense against the dark arts
  2. 2. Yan Cui http://theburningmonk.com @theburningmonk AWS user for 10 years
  3. 3. http://bit.ly/yubl-serverless
  4. 4. Yan Cui http://theburningmonk.com @theburningmonk Developer Advocate @
  5. 5. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant
  6. 6. Shared Responsibility Model
  7. 7. Shared Responsibility Model
  8. 8. protection from OS attacks Amazon automatically apply latest patches to host VMs
  9. 9. still have to patch your code vulnerable code, 3rd party dependencies, etc.
  10. 10. https://snyk.io/blog/owasp-top-10-breaches
  11. 11. https://snyk.io/blog/owasp-top-10-breaches Known Vulnerable Components cause 24% of the top 50 data breaches
  12. 12. https://snyk.io/blog/77-percent-of-sites-use-vulnerable-js-libraries
  13. 13. http://bit.ly/2topw5I
  14. 14. use prepared statements
  15. 15. sanitise inputs & outputs (standardise and encapsulate into shared lib)
  16. 16. security is as much about what your function should do as well as what it shouldn’t do (protect against data exfiltration)
  17. 17. http://bit.ly/2gSHtay Broken Access Control Insecure Direct Object Reference Information Leakage GraphQL Injection
  18. 18. http://bit.ly/2uKhGXF
  19. 19. app dependencies is a attack surface BIGGER than you think
  20. 20. your dependencies
  21. 21. your dependencies transient dependencies
  22. 22. https://david-dm.org/request/request?view=tree
  23. 23. https://snyk.io
  24. 24. security updates are often bundled with unrelated feature and API changes
  25. 25. your security is as strong as its weakest link
  26. 26. 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
  27. 27. 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
  28. 28. 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, …
  29. 29. people are often the WEAKEST link in the security chain
  30. 30. 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
  31. 31. 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
  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 brute force, known account leaks, … Networking runs on needs Source Code has maintains
  33. 33. http://bit.ly/2sFDwYX …obtained publish access to 14% of npm packages…
  34. 34. http://bit.ly/2sFDwYX debug, request, react, co, express, moment, gulp, mongoose, mysql, bower, browserify, electron, jasmine, cheerio, modernizr, redux, …
  35. 35. 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.
  36. 36. 20% of all monthly NPM downloads…
  37. 37. brute force known account leaks from other sources leaked NPM credentials (github, etc.)
  38. 38. http://bit.ly/2sFDwYX
  39. 39. http://bit.ly/2sFDwYX 662 users had password “123456” 172 — “123” 124 — “password”
  40. 40. WTF!?!?
  41. 41. oh god, that was too easy…
  42. 42. compromised package is a transient dependency sigh…
  43. 43. still “works”…
  44. 44. npmjs.com/~hacktask
  45. 45. rm -rf /!!!
  46. 46. NPM default - get latest “compatible” version, ie. 1.X.X
  47. 47. 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
  48. 48. use npm shrinkwrap or upgrade to NPM 5 or above
  49. 49. use `npm ci` in CI environment
  50. 50. not specific to Node.js or NPM
  51. 51. the attackers are in…
  52. 52. the attackers are in… what now?
  53. 53. Shared Responsibility Model
  54. 54. who can invoke the function?
  55. 55. what can the function access?
  56. 56. Least Privilege Principle
  57. 57. everything here is trusted
  58. 58. sensitive data
  59. 59. http://bit.ly/2zHvbcB
  60. 60. always public access is controlled via IAM
  61. 61. https://www.puresec.io/function-shield
  62. 62. http://bit.ly/2lNInES
  63. 63. adds up to 10s to cold start!! http://bit.ly/2lNInES
  64. 64. compromised servers allow attacker to access all of your sensitive data!
  65. 65. implement authentication and authorization for internal APIs
  66. 66. use AWS_IAM authentication for internal APIs
  67. 67. minimise function’s access
  68. 68. requires developer discipline
  69. 69. 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
  70. 70. S3 AWS IoT DynamoDB RDS EventStore Elasticsearch Couchbase Redshift Neo4j Google BigQuery
  71. 71. secure sensitive data both at rest and in-transit
  72. 72. leverage server-side encryption
  73. 73. http://amzn.to/1N3Twb8
  74. 74. http://amzn.to/1xF41eX
  75. 75. http://amzn.to/2tgvFR2
  76. 76. https://amzn.to/2DaXFwA
  77. 77. Least Privilege Principle
  78. 78. Disposability is a virtue
  79. 79. AWS Lambda docs Delete old Lambda functions that you are no longer using. http://amzn.to/2jzLmkb
  80. 80. easier said than done…
  81. 81. identifying component ownership in a big IT organization is challenging
  82. 82. identifying ownership of individual functions is much harder
  83. 83. tag every function with Team name
  84. 84. source: http://www.digitalattackmap.com
  85. 85. more likely to scale through DoS attacks
  86. 86. DoS + per exec billing = Denial of Wallet problem
  87. 87. configure WAF rules on API Gateway and CloudFront
  88. 88. review the default API Gateway throttling settings
  89. 89. 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.
  90. 90. async sync S3 SNS SES CloudFormation CloudWatch Logs CloudWatch Events Scheduled Events CodeCommit AWS Config http://amzn.to/2vs2lIg Cognito Alexa Lex API Gateway pulling DynamoDB Stream Kinesis Stream SQS Lambda handles retries (twice, then DLQ)
  91. 91. http://bit.ly/2v7F2E4
  92. 92. DoS attack 2+ Retries+ ?
  93. 93. DoS attack Regex DoS attack long Lambda timeout 2+ Retries+ ?
  94. 94. avoid (unnecessary) long timeouts
  95. 95. alert on error rate
  96. 96. Day 1
  97. 97. Day 2
  98. 98. no long-lived compromised servers
  99. 99. containers are reused, avoid sensitive data in /tmp
  100. 100. https://www.puresec.io/function-shield
  101. 101. no accidentally exposed directories
  102. 102. cryptojacking
  103. 103. http://bit.ly/2tlGTbc
  104. 104. monitor activities in unused regions using CloudWatch Events
  105. 105. set up billing alarms in unused regions
  106. 106. watertight compartments that can contain water in the case of hull breach or other leaks
  107. 107. Michael Nygard
  108. 108. least privilege principle
  109. 109. per function policies
  110. 110. account level isolation
  111. 111. Recap
  112. 112. app dependencies is a attack surface BIGGER than you think
  113. 113. sanitise inputs and outputs
  114. 114. Least Privilege Principle
  115. 115. here’s your per function policy NEXT!
  116. 116. S3 AWS IoT DynamoDB RDS EventStore Elasticsearch Couchbase Redshift Neo4j Google BigQuery encrypt data at rest
  117. 117. S3 AWS IoT DynamoDB RDS EventStore Elasticsearch Couchbase Redshift Neo4j Google BigQuery and in-transit
  118. 118. delete unused functions.
  119. 119. DoS DoW* * Denial of Wallet
  120. 120. no server* no OS attacks no long lived compromised servers * I know I know, there’s still a server somewhere, but it’s managed and secured by AWS engineers who can do a much better job of it than most of us can; and the servers are ephemeral and short-lived
  121. 121. don’t be an unwilling bit miner
  122. 122. don’t be an unwilling bit miner safeguard your credentials…
  123. 123. prod dev compartmentalise breaches
  124. 124. people are often the WEAKEST link in the security chain
  125. 125. @theburningmonk theburningmonk.com github.com/theburningmonk
  126. 126. https://theburningmonk.com/hire-me AdviseTraining Delivery

×