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: What's Left To Protect

559 views

Published on

Serverless means handing off server management to the cloud platforms – along with their security risks. With the “pros” ensuring our servers are patched, what’s left for application owners to protect? As it turns out, quite a lot.

This talk discusses the aspects of security serverless doesn’t solve, the problems it could make worse, and the tools and practices you can use to keep yourself safe.

Required audience experience
Basic knowledge of how FaaS and Serverless works

Objective of the talk
As many companies explore the world of serverless, it’s important they understand the aspects of security this new world helps them with, and the ones they need to care more about. This talk will provide a framework to understand how to prioritise and approach security for Serverless apps.

Published in: Software
  • Be the first to comment

Serverless Security: What's Left To Protect

  1. 1. snyk.io Serverless Security:
 What’s Left to Protect? Guy Podjarny, Snyk @guypod
  2. 2. snyk.io About Me • Guy Podjarny, @guypod on Twitter • CEO & Co-founder at Snyk • History: • Cyber Security part of Israel Defense Forces • First Web App Firewall(AppShield), Dynamic/Static Tester(AppScan) • Security: Worked in Sanctum -> Watchfire -> IBM • Performance: Founded Blaze -> CTO @Akamai • O’Reilly author, speaker
  3. 3. snyk.io Serverless
 Changes Security
  4. 4. snyk.io Serverless Is… Better for some security concerns Neutral for some security concerns Worse for some security concerns
  5. 5. snyk.io When is Serverless 
 Better for Security?
  6. 6. snyk.io Serverless has no Servers! (that you manage and secure)
  7. 7. snyk.io Vulnerable
 OS Dependencies “patching”your servers Less need to worry about…
  8. 8. snyk.io Heartbleed
  9. 9. snyk.io Shellshock
  10. 10. snyk.io
  11. 11. snyk.io Verizon:
 “Most attacks exploit known vulnerabilities that have never been patched despite patches being available for months, or even years”
  12. 12. snyk.io Symantec: 
 “Through 2020, 99% of vulnerabilities exploited will continue to be ones known by security and IT professionals for at least one year”
  13. 13. snyk.io With Serverless, it’s the
 platform’s responsibility And it’s the platform operators core competency
  14. 14. snyk.io FaaS ~= PaaS FaaS naturally relies less on OS dependencies
  15. 15. snyk.io Denial of Service Less need to worry about…
  16. 16. snyk.io DoS means a stream of
 specific“heavy”requests
 take down server(s)(e.g. ReDoS). In FaaS, there is no long standing server to take down
  17. 17. snyk.io Auto Scale FTW! Deal with bad demand just like dealing with good demand
  18. 18. snyk.io Caveat: 
 Concurrent execution limit AWS Lambda default limit 1000 concurrent function executions pre region
  19. 19. snyk.io Caveat: 
 Resource exhaustion Back-end resources are often not equally elastic
  20. 20. snyk.io Caveat: 
 Limited in size 100Gbps attack will still take you down…
 Consider a DDoS protection solution too.
  21. 21. snyk.io Caveat: 
 Your bill You still pay for extra traffic…
  22. 22. snyk.io Long-lived Compromised Servers Less need to worry about…
  23. 23. snyk.io Attackers penetrate 
 in stages
  24. 24. snyk.io Attackers like to lay in wait
  25. 25. snyk.io FaaS forces Statelessness -
 including bad state Attackers need to repeat attacks many times, risking detection & remediation
  26. 26. snyk.io Caveat: 
 Containers are often reused A compromised function may still compromise other users
  27. 27. snyk.io FaaS > PaaS PaaS Servers are managed, but still live longer
  28. 28. snyk.io Security in Serverless Vulnerable OS Dependencies Denial of Service Long-lived Compromised Servers Better
  29. 29. snyk.io So attackers will go… ¯_(ツ)_/¯ Right?
  30. 30. snyk.io When is Serverless 
 Neutral for Security?
  31. 31. snyk.io Permissions and authorization Still need to worry about…
  32. 32. snyk.io Who can invoke your function?
  33. 33. snyk.io Who can access code & 
 env vars for your function?
  34. 34. snyk.io If your function was compromised, what can it do?
  35. 35. snyk.io AWS Security Policy
  36. 36. snyk.io AWS Security Policy Easier Policy 3Policy 2 Policy 1 Safer
  37. 37. snyk.io Keep your policies granular
  38. 38. snyk.io iRobot automates IAM roles https://www.youtube.com/watch?v=BVVHzCd8APw
  39. 39. snyk.io Use Least Privilege Principle
  40. 40. snyk.io Policies continuously expand until somebody adds an asterix
  41. 41. snyk.io Adding permissions is easy.
 Removing permissions is hard
  42. 42. snyk.io Caveat:
 FaaS permissions are limited to
 Platform actions
  43. 43. snyk.io PureSec FunctionShield
  44. 44. snyk.io Serverless is a bit better
 for authorization if managed properly, which it often isn’t
  45. 45. snyk.io Securing Data(at rest) Still need to worry about…
  46. 46. snyk.io FaaS apps still store data and that data can be stolen or tampered with
  47. 47. snyk.io Bad:
 FaaS means more state 
 outside the server can no longer keep sensitive data “on the machine”
  48. 48. snyk.io Good:
 FaaS allows more granular
 data access controls Control which functions can access which data
  49. 49. snyk.io Tips & Tricks • Encrypt all sensitive persistent data • Encrypt all sensitive off-box state data • Minimize functions that can access each data store • Use separate DB credentials per function • And control what these credentials should do • Monitor which functions are accessing which data
  50. 50. snyk.io Vulnerabilities in 
 Your Code Still need to worry about…
  51. 51. snyk.io Serverless doesn’t protect
 the Application Layer
  52. 52. snyk.io SQL Injection Cross Site Scripting Remote Command Execution Cross Site Request Forgery Bad auth logic …
  53. 53. snyk.io https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
  54. 54. snyk.io App Sec Tips • Dynamic App Sec Testing • Static App Sec Testing • Standardize input processing to include sanitization • Use shared libraries across functions • Make API Gateway models as strict as possible • Secure each function independently • Secure unit tests FTW!
  55. 55. snyk.io Vulnerable
 Application Dependencies Still need to worry about…
  56. 56. snyk.io Serverless functions use
 Application Dependencies npm, Maven, PyPI, nuget…
  57. 57. snyk.io For many functions, the majority 
 of code is dependencies 3rd party code can hold vulnerabilities just like 1st party code
  58. 58. snyk.io Example: Fetch file & store in s3 (Serverless Framework Example) 19 Lines of Code 2 Direct dependencies 19 dependencies(incl. indirect) 191,155 Lines of Code
  59. 59. snyk.io More code ~= 
 More Vulnerabilities
  60. 60. snyk.io Over time, dependencies grow
 stale & vulnerable
  61. 61. snyk.io
  62. 62. snyk.io The platform manages 
 OS Dependencies.
 
 You need to manage 
 App Dependencies.
  63. 63. snyk.io <Shameless Plug>
  64. 64. snyk.io Snyk for Serverless!
 (and PaaS)
  65. 65. snyk.io Snyk for Serverless!
 (and PaaS)
  66. 66. snyk.io Fix during Dev
  67. 67. snyk.io </Shameless Plug>
  68. 68. snyk.io Security in Serverless Vulnerabilities in your code Vulnerable App Dependencies Permissions Securing Data at rest Vulnerable OS Dependencies Denial of Service Long-lived Compromised Servers Better Neutral
  69. 69. snyk.io Neutral ~= Worse By eliminating some threats, 
 Serverless shifts attacker attention to what’s left
  70. 70. snyk.io When is Serverless 
 Worse for Security?
  71. 71. snyk.io Serverless doesn’t create 
 new security problems.
  72. 72. snyk.io Serverless means more… 
 Independent Services Flexible Interfaces Use of 3rd party services including the risks that entails!
  73. 73. snyk.io Third Party Services and securing data in transit More need to worry about…
  74. 74. snyk.io What data are you sharing? and how well does the other service manage it? For each service, worry about…
  75. 75. snyk.io Is data in transit secured? Is it using HTTPS? Is it within a VPC? Is it encrypted? For each service, worry about…
  76. 76. snyk.io Who are you talking to? You use an API key, but how do you authenticate them?
 Validate HTTPS cert, especially when exiting your network For each service, worry about…
  77. 77. snyk.io Do you trust its responses? If the other service is compromised, can it be used to get to you? For each service, worry about…
  78. 78. snyk.io How to store API keys? Be sure to use a KMS and rotate keys! For each service, worry about…
  79. 79. snyk.io For each service, worry about… • What data are you sharing? • Is data in transit secured? • Who are you talking to? • Do you trust its responses? • How to store API keys?
  80. 80. snyk.io Worry about 
 1st party services too! Don’t let your least secure function take down the system
  81. 81. snyk.io Use
 AWS X-Ray
 for visibility Image via Yan Cui’s blog
  82. 82. snyk.io Attack Surface mo’ functions, mo’ problems More need to worry about…
  83. 83. snyk.io Serverless -> Granularity ->
 Flexibility
  84. 84. snyk.io Flexibility -> Risk Harder to define what’s “right”, more use-cases to abuse
  85. 85. snyk.io A function is a perimeter That needs to be secured Perimeter Perimeter Perimeter Perimeter Perimeter
  86. 86. snyk.io Tips & Tricks • Test every function for security flaws, independently • Don’t rely on limiting access to a function • Access controls will change over time, without code changes • Use shared input/output processing libraries • Make it easier to process input securely than insecurely • Limit functionality to what you actually need • Sometimes you need to work more to let functions do less • Monitor both individual functions and full flows
  87. 87. snyk.io Security Monitoring mo’ functions, mo’ problems More need to worry about…
  88. 88. snyk.io Why NOT
 deploy a function? Super easy,(effectively)zero cost
  89. 89. snyk.io Easy deployment + min cost = LOTS of functions Many of which are lightly used
  90. 90. snyk.io Easy to add,
 Hard to remove
  91. 91. snyk.io Policies tend to expand… Expanding is easy, contracting is hard
  92. 92. snyk.io LOTS of functions,
 many of which are lightly used,
 with overly open policies… our future?
  93. 93. snyk.io Every Function 
 introduces Risk
  94. 94. snyk.io No ops cost != 
 No cost of ownership Risk & Management costs still exist
  95. 95. snyk.io Tips & Tricks • Consider before you deploy. Do you need this? • Separate networks/accounts for groups of functions • Track what you have deployed, and how it’s used • Minimize permissions up front • Chaos-style reduce permissions and see what breaks • Monitor for known vulnerabilities in functions
  96. 96. snyk.io Security in Serverless Vulnerabilities in your code Vulnerable App Dependencies Permissions Securing Data at rest Vulnerable OS Dependencies Denial of Service Long-lived Compromised Servers Third Party Services Attack Surface Security Monitoring Better Neutral Worse
  97. 97. snyk.io Tools?
  98. 98. snyk.io https://thenewstack.io/serverless-roadmaps-monitoring-security-frameworks-tools/
  99. 99. snyk.io Monitor attacks in the SOCC
 (Security Operation Control Center) PureSec Twistlock Protego
  100. 100. snyk.io Monitor & Fix vulnerable libs 
 in Dev & CI/CD
  101. 101. snyk.io Summary
  102. 102. snyk.io Serverless dramatically reduces some top security threats
  103. 103. snyk.io But…
  104. 104. snyk.io Security is hard - 
 and attackers don’t give up
  105. 105. snyk.io Serverless shuffles 
 security priorities Previously easy attacks are now hard.
 Attackers will move on to the next item on the list

  106. 106. snyk.io Security in Serverless Vulnerabilities in your code Vulnerable App Dependencies Permissions Securing Data at rest Vulnerable OS Dependencies Denial of Service Long-lived Compromised Servers Third Party Services Attack Surface Security Monitoring Better Neutral Worse
  107. 107. snyk.io Serverless is defined now.
 Let’s build Security in. Thank You! Guy Podjarny, Snyk @guypod

×