Serverless Security: What's Left To Protect
•
4 likes•1,908 views
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.
Report
Share
More Related Content
What's hot
What's hot (20)
Similar to Serverless Security: What's Left To Protect
Similar to Serverless Security: What's Left To Protect (20)
More from Guy Podjarny
More from Guy Podjarny (18)
Recently uploaded
Recently uploaded (20)
Serverless Security: What's Left To Protect
- 1. snyk.io Serverless Security: What’s Left to Protect? Guy Podjarny, Snyk @guypod
- 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
- 4. snyk.io Serverless Is… Better for some security concerns Neutral for some security concerns Worse for some security concerns
- 5. snyk.io When is Serverless Better for Security?
- 6. snyk.io Serverless has no Servers! (that you manage and secure)
- 7. snyk.io Vulnerable OS Dependencies “patching”your servers Less need to worry about…
- 10. snyk.io
- 11. snyk.io Verizon: “Most attacks exploit known vulnerabilities that have never been patched despite patches being available for months, or even years”
- 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. snyk.io With Serverless, it’s the platform’s responsibility And it’s the platform operators core competency
- 14. snyk.io FaaS ~= PaaS FaaS naturally relies less on OS dependencies
- 15. snyk.io Denial of Service Less need to worry about…
- 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. snyk.io Auto Scale FTW! Deal with bad demand just like dealing with good demand
- 18. snyk.io Caveat: Concurrent execution limit AWS Lambda default limit 1000 concurrent function executions pre region
- 19. snyk.io Caveat: Resource exhaustion Back-end resources are often not equally elastic
- 20. snyk.io Caveat: Limited in size 100Gbps attack will still take you down… Consider a DDoS protection solution too.
- 21. snyk.io Caveat: Your bill You still pay for extra traffic…
- 22. snyk.io Long-lived Compromised Servers Less need to worry about…
- 23. snyk.io Attackers penetrate in stages
- 24. snyk.io Attackers like to lay in wait
- 25. snyk.io FaaS forces Statelessness - including bad state Attackers need to repeat attacks many times, risking detection & remediation
- 26. snyk.io Caveat: Containers are often reused A compromised function may still compromise other users
- 27. snyk.io FaaS > PaaS PaaS Servers are managed, but still live longer
- 28. snyk.io Security in Serverless Vulnerable OS Dependencies Denial of Service Long-lived Compromised Servers Better
- 29. snyk.io So attackers will go… ¯_(ツ)_/¯ Right?
- 30. snyk.io When is Serverless Neutral for Security?
- 31. snyk.io Permissions and authorization Still need to worry about…
- 32. snyk.io Who can invoke your function?
- 33. snyk.io Who can access code & env vars for your function?
- 34. snyk.io If your function was compromised, what can it do?
- 36. snyk.io AWS Security Policy Easier Policy 3Policy 2 Policy 1 Safer
- 37. snyk.io Keep your policies granular
- 38. snyk.io iRobot automates IAM roles https://www.youtube.com/watch?v=BVVHzCd8APw
- 39. snyk.io Use Least Privilege Principle
- 40. snyk.io Policies continuously expand until somebody adds an asterix
- 41. snyk.io Adding permissions is easy. Removing permissions is hard
- 42. snyk.io Caveat: FaaS permissions are limited to Platform actions
- 44. snyk.io Serverless is a bit better for authorization if managed properly, which it often isn’t
- 45. snyk.io Securing Data(at rest) Still need to worry about…
- 46. snyk.io FaaS apps still store data and that data can be stolen or tampered with
- 47. snyk.io Bad: FaaS means more state outside the server can no longer keep sensitive data “on the machine”
- 48. snyk.io Good: FaaS allows more granular data access controls Control which functions can access which data
- 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. snyk.io Vulnerabilities in Your Code Still need to worry about…
- 51. snyk.io Serverless doesn’t protect the Application Layer
- 52. snyk.io SQL Injection Cross Site Scripting Remote Command Execution Cross Site Request Forgery Bad auth logic …
- 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. snyk.io Vulnerable Application Dependencies Still need to worry about…
- 56. snyk.io Serverless functions use Application Dependencies npm, Maven, PyPI, nuget…
- 57. snyk.io For many functions, the majority of code is dependencies 3rd party code can hold vulnerabilities just like 1st party code
- 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. snyk.io More code ~= More Vulnerabilities
- 60. snyk.io Over time, dependencies grow stale & vulnerable
- 61. snyk.io
- 62. snyk.io The platform manages OS Dependencies. You need to manage App Dependencies.
- 64. snyk.io Snyk for Serverless! (and PaaS)
- 65. snyk.io Snyk for Serverless! (and PaaS)
- 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. snyk.io Neutral ~= Worse By eliminating some threats, Serverless shifts attacker attention to what’s left
- 70. snyk.io When is Serverless Worse for Security?
- 71. snyk.io Serverless doesn’t create new security problems.
- 72. snyk.io Serverless means more… Independent Services Flexible Interfaces Use of 3rd party services including the risks that entails!
- 73. snyk.io Third Party Services and securing data in transit More need to worry about…
- 74. snyk.io What data are you sharing? and how well does the other service manage it? For each service, worry about…
- 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. 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. 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. snyk.io How to store API keys? Be sure to use a KMS and rotate keys! For each service, worry about…
- 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. snyk.io Worry about 1st party services too! Don’t let your least secure function take down the system
- 81. snyk.io Use AWS X-Ray for visibility Image via Yan Cui’s blog
- 82. snyk.io Attack Surface mo’ functions, mo’ problems More need to worry about…
- 83. snyk.io Serverless -> Granularity -> Flexibility
- 84. snyk.io Flexibility -> Risk Harder to define what’s “right”, more use-cases to abuse
- 85. snyk.io A function is a perimeter That needs to be secured Perimeter Perimeter Perimeter Perimeter Perimeter
- 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. snyk.io Security Monitoring mo’ functions, mo’ problems More need to worry about…
- 88. snyk.io Why NOT deploy a function? Super easy,(effectively)zero cost
- 89. snyk.io Easy deployment + min cost = LOTS of functions Many of which are lightly used
- 90. snyk.io Easy to add, Hard to remove
- 91. snyk.io Policies tend to expand… Expanding is easy, contracting is hard
- 92. snyk.io LOTS of functions, many of which are lightly used, with overly open policies… our future?
- 93. snyk.io Every Function introduces Risk
- 94. snyk.io No ops cost != No cost of ownership Risk & Management costs still exist
- 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. 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. snyk.io Tools?
- 99. snyk.io Monitor attacks in the SOCC (Security Operation Control Center) PureSec Twistlock Protego
- 100. snyk.io Monitor & Fix vulnerable libs in Dev & CI/CD
- 101. snyk.io Summary
- 102. snyk.io Serverless dramatically reduces some top security threats
- 103. snyk.io But…
- 104. snyk.io Security is hard - and attackers don’t give up
- 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. 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. snyk.io Serverless is defined now. Let’s build Security in. Thank You! Guy Podjarny, Snyk @guypod