1. Serverless Security
defense against the
dark arts

2. Shared Responsibility Model

3. Shared Responsibility Model

4. protection from OS attacks
Amazon automatically apply latest patches to host VMs

7. Shared Responsibility Model

8. still have to patch your code
vulnerable code, 3rd party dependencies, etc.

10. https://snyk.io/blog/owasp-top-10-breaches

11. https://snyk.io/blog/owasp-top-10-breaches
Known Vulnerable Components cause 24% of the top 50 data breaches

12. https://snyk.io/blog/77-percent-of-sites-use-vulnerable-js-libraries

17. http://bit.ly/2topw5I

18. use prepared statements

19. sanitise inputs & outputs
(standardise and encapsulate into shared lib)

20. security is as much about what your function
should do as well as what it shouldn’t do
(protect against data exfiltration)

22. http://bit.ly/2gSHtay
Broken Access Control
Insecure Direct Object Reference
Information Leakage
GraphQL Injection

23. http://bit.ly/2uKhGXF

25. Yan Cui
http://theburningmonk.com
@theburningmonk
AWS user for 10 years

26. http://bit.ly/yubl-serverless

27. Yan Cui
http://theburningmonk.com
@theburningmonk
Developer Advocate @

29. Yan Cui
http://theburningmonk.com
@theburningmonk
Independent Consultant
advisetraining delivery

30. theburningmonk.com/courses

31. theburningmonk.com/courses

32. realworldserverless.com

33. app dependencies
is a
attack surface
BIGGER
than you think

34. your dependencies

35. your dependencies
transient dependencies

36. https://david-dm.org/request/request?view=tree

38. https://snyk.io

39. security updates are often
bundled with unrelated
feature and API changes

40. your security is as strong
as its weakest link

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

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

44. 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, …

45. people are often the WEAKEST link
in the security chain

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

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

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

50. http://bit.ly/2sFDwYX
…obtained publish access to 14% of npm packages…

51. http://bit.ly/2sFDwYX
debug, request, react, co, express, moment, gulp, mongoose, mysql, bower,
browserify, electron, jasmine, cheerio, modernizr, redux, …

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

53. 20% of all monthly NPM downloads…

54. brute force
known account leaks from other sources
leaked NPM credentials (github, etc.)

55. http://bit.ly/2sFDwYX

56. http://bit.ly/2sFDwYX
662 users had password “123456”
172 — “123”
124 — “password”

61. WTF!?!?

66. oh god, that was too easy…

69. compromised package is a
transient dependency
sigh…

70. still “works”…

73. npmjs.com/~hacktask

75. rm -rf /!!!

77. NPM default - get latest
“compatible” version, ie. 1.X.X

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

80. use `npm ci` in CI environment

81. not specific to Node.js or NPM

82. the attackers are in…

83. the attackers are in…
what now?

84. Shared Responsibility Model

85. who can invoke the function?

86. what can the function access?

87. Least Privilege Principle

89. everything here
is trusted

91. sensitive data

92. http://bit.ly/2zHvbcB

93. always public
access is controlled via IAM

98. compromised servers allow
attacker to access all of
your sensitive data!

99. implement authentication and
authorization for every API
aka. zero-trust networking

101. Which auth method
should I use?

102. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method

103. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method

104. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method

105. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method

106. https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method

107. DON’T authenticate in the
API function itself!

108. minimise function’s access

112. requires developer discipline

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

116. S3
AWS IoT
DynamoDB
RDS
EventStore
Elasticsearch Couchbase
Redshift
Neo4j
Google BigQuery

117. secure sensitive data both
at rest and in-transit

118. leverage server-side encryption

119. http://amzn.to/1N3Twb8

120. http://amzn.to/1xF41eX

121. http://amzn.to/2tgvFR2

122. https://amzn.to/2DaXFwA

123. Least Privilege Principle

124. Disposability is a virtue

125. AWS Lambda
docs
Delete old Lambda functions that
you are no longer using.
http://amzn.to/2jzLmkb

126. easier said than done…

127. identifying component
ownership in a big IT
organization is challenging

128. identifying ownership of
individual functions is
much harder

129. tag every function with Team name

130. source: http://www.digitalattackmap.com

131. more likely to scale through
DoS attacks

132. DoS + per exec billing =
Denial of Wallet problem

133. configure WAF rules on
API Gateway or CloudFront

134. review the default API Gateway
throttling settings

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

137. avoid (unnecessary) long timeouts

138. alert on error rate

140. cryptojacking

143. http://bit.ly/2tlGTbc

144. monitor activities in unused regions
using CloudWatch Events

146. disable inactive regions & services
using AWS Organization and SCPs

147. https://github.com/OlafConijn/AwsOrganizationFormation

149. https://www.youtube.com/watch?v=mLAGHzidHJ0

150. watertight compartments that can contain water in
the case of hull breach or other leaks

151. Michael Nygard

152. least privilege principle

153. per function policies

154. account level isolation

155. @theburningmonk theburningmonk.com

156. Recap

157. app dependencies
is a
attack surface
BIGGER
than you think

159. sanitise inputs and outputs

160. Least Privilege Principle

161. here’s your per function policy
NEXT!

162. S3
AWS IoT
DynamoDB
RDS
EventStore
Elasticsearch Couchbase
Redshift
Neo4j
Google BigQuery
encrypt data at rest

163. S3
AWS IoT
DynamoDB
RDS
EventStore
Elasticsearch Couchbase
Redshift
Neo4j
Google BigQuery
and in-transit

164. delete unused functions.

165. DoS DoW*
* Denial of Wallet

167. don’t be an unwilling bit miner

168. don’t be an unwilling bit miner
safeguard your credentials…

169. prod dev
compartmentalise breaches

170. people are often the WEAKEST link
in the security chain

171. @theburningmonk theburningmonk.com
lambdabestpractice.com

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

173. @theburningmonk
theburningmonk.com
github.com/theburningmonk