Slides from my ServerlessConf Austin 2017. 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

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

3. snyk.io
Serverless
Changes Security

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…

8. snyk.io
Verizon:
“Most attacks exploit known
vulnerabilities that have never been
patched despite patches being
available for months, or even years”

9. 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”

10. snyk.io
With Serverless, it’s the
platform’s responsibility
And it’s the platform operators core competency

11. snyk.io
FaaS ~= PaaS
FaaS naturally relies less on OS dependencies

12. snyk.io
Denial of Service
Less need to worry about…

13. 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

14. snyk.io
Auto Scale FTW!
Deal with bad demand just like dealing with good demand

15. snyk.io
Caveat:
Concurrent execution limit
AWS Lambda default limit 600 concurrent function executions

16. snyk.io
Caveat:
Your bill
You still pay for extra traffic…

17. snyk.io
Caveat:
Limited in size
100Gbps attack will still take you down…
Consider a DDoS protection solution too.

18. snyk.io
Long-lived
Compromised Servers
Less need to worry about…

19. snyk.io
Attackers penetrate
in stages

20. snyk.io
Attackers like to lay in wait

21. snyk.io
FaaS forces Statelessness -
including bad state
Attackers need to repeat attacks many times, risking detection & remediation

22. snyk.io
Caveat:
Containers may be reused
Avoid private data in /tmp/

23. snyk.io
FaaS > PaaS
PaaS Servers are managed, but still live longer

24. snyk.io
Security in Serverless
Vulnerable OS Dependencies
Denial of Service
Long-lived Compromised
Servers
Better

25. snyk.io
So attackers will go…
¯_(ツ)_/¯
Right?

26. snyk.io
When is Serverless
Neutral for Security?

27. snyk.io
Permissions
and authorization
Still need to worry about…

28. snyk.io
Who can invoke your
function?

29. snyk.io
Who can access code &
env vars for your function?

30. snyk.io
If your function was
compromised, what can it do?

31. snyk.io
AWS Security Policy
Easier
Policy 3Policy 2
Policy 1
Safer

32. snyk.io
Keep your policies granular

33. snyk.io
Use Least Privilege Principle

34. snyk.io
Adding permissions is easy.
Removing permissions is hard

35. snyk.io
Serverless is a bit better
for authorization
if managed properly, which it often isn’t

36. snyk.io
Securing Data (at rest)
Still need to worry about…

37. snyk.io
FaaS apps still store data
and that data can be stolen or tampered with

38. snyk.io
FaaS means more state
outside the server
can no longer keep sensitive data “on the machine”

39. snyk.io
FaaS allows more granular
data access controls
Control which functions can access which data

40. 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

41. snyk.io
Vulnerabilities in
Your Code
Still need to worry about…

42. snyk.io
Serverless doesn’t protect
the Application Layer

43. snyk.io
SQL Injection
Cross Site Scripting
Remote Command Execution
Cross Site Request Forgery
Bad auth logic
…

44. snyk.io https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

45. snyk.io
App Sec Tips
• Dynamic App Sec Testing (e.g. OWASP Zap)
• Static App Sec Testing (e.g. Codiscope Jacks)
• Standardize input processing to include sanitization
• Make API Gateway models as strict as possible
• Secure each function independently

46. snyk.io
Vulnerable
Application Dependencies
Still need to worry about…

47. snyk.io
Serverless functions use
Application Dependencies
npm, Maven, PyPI, nuget…

48. snyk.io
For many functions, the majority
of code is dependencies
3rd party code can hold vulnerabilities just like 1st party code

49. 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

50. snyk.io
More code ~=
More Vulnerabilities

51. snyk.io
Over time, dependencies grow
stale & vulnerable

52. snyk.io
The platform manages
OS Dependencies.
You need to manage
App Dependencies.

53. snyk.io
Announcing
Snyk for Serverless!
Continuously monitor for vulnerable dependencies in your functions
(and PaaS apps)

54. snyk.io
Snyk for Serverless!
(and PaaS)

55. snyk.io
Snyk for Serverless!
(and PaaS)

56. snyk.io
Snyk for Serverless!
(and PaaS)

57. snyk.io
Snyk for Serverless!

58. 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

59. snyk.io
Neutral ~= Worse
By eliminating some threats,
Serverless shifts attacker attention to what’s left

60. snyk.io
When is Serverless
Worse for Security?

61. snyk.io
Serverless doesn’t create
new security problems.

62. snyk.io
Serverless means more…
Independent Services
Flexible Interfaces
Use of 3rd party services
including the risks that entails!

63. snyk.io
Third Party Services
and securing data in transit
More need to worry about…

64. snyk.io
What data are you sharing?
and how well does the other service manage it?
For each service, worry about…

65. snyk.io
Is data in transit secured?
Is it using HTTPS? Is it within a VPC? Is it encrypted?
For each service, worry about…

66. 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…

67. 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…

68. snyk.io
How to store API keys?
Be sure to use a KMS and Env Variables!
For each service, worry about…

69. 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?

70. snyk.io
Worry about
1st party services too!
Don’t let your least secure function take down the system

71. snyk.io
Tools?

72. snyk.io
Attack Surface
mo’ functions, mo’ problems
More need to worry about…

73. snyk.io
Serverless -> Granularity ->
Flexibility

74. snyk.io
Flexibility -> Risk
Harder to define what’s “right”, more use-cases to abuse

75. snyk.io
A function is a perimeter
That needs to be secured
Perimeter Perimeter
Perimeter
Perimeter
Perimeter

76. 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

77. snyk.io
Security Monitoring
mo’ functions, mo’ problems
More need to worry about…

78. snyk.io
Why NOT
deploy a function?
Super easy, (effectively)zero cost

79. snyk.io
Easy deployment + min cost =
LOTS of functions
Many of which are lightly used

80. snyk.io
Easy to add,
Hard to remove

81. snyk.io
Policies tend to expand…
Expanding is easy, contracting is hard

82. snyk.io
LOTS of functions,
many of which are lightly used,
with overly open policies…
our future?

83. snyk.io
Every Function
introduces Risk

84. snyk.io
No ops cost !=
No cost of ownership
Risk & Management costs still exist

85. 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

86. snyk.io
Monitor for Vulnerable
App Dependencies

87. 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

88. snyk.io
Summary

89. snyk.io
Serverless dramatically reduces
some top security threats

90. snyk.io
But…

91. snyk.io
Security is hard -
and attackers don’t give up

92. snyk.io
Serverless shuffle
security priorities
Previously easy attacks are now hard.
Attackers will move on to the next item on the list

93. 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

94. snyk.io
Serverless is defined now.
Let’s build Security in.
Thank You!
Guy Podjarny, Snyk
@guypod