1.
Serverless Security
defense against the
dark arts

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

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

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

5.
Yan Cui
http://theburningmonk.com
@theburningmonk
Independent Consultant

6.
Shared Responsibility Model

7.
Shared Responsibility Model

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

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

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

14.
use prepared statements

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

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

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

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

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

20.
your dependencies

21.
your dependencies
transient dependencies

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

23.
https://snyk.io

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

25.
your security is as strong
as its weakest link

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.
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.
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.
people are often the WEAKEST link
in the security chain

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.
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.
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.
http://bit.ly/2sFDwYX
…obtained publish access to 14% of npm packages…

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

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.
20% of all monthly NPM downloads…

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

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

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

40.
WTF!?!?

41.
oh god, that was too easy…

42.
compromised package is a
transient dependency
sigh…

43.
still “works”…

44.
npmjs.com/~hacktask

45.
rm -rf /!!!

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

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.
use npm shrinkwrap
or upgrade to NPM 5 or above

49.
use `npm ci` in CI environment

50.
not specific to Node.js or NPM

51.
the attackers are in…

52.
the attackers are in…
what now?

53.
Shared Responsibility Model

54.
who can invoke the function?

55.
what can the function access?

56.
Least Privilege Principle

57.
everything here
is trusted

58.
sensitive data

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

60.
always public
access is controlled via IAM

61.
https://www.puresec.io/function-shield

62.
http://bit.ly/2lNInES

63.
adds up to 10s to cold start!!
http://bit.ly/2lNInES

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

65.
implement authentication and
authorization for internal APIs

66.
use AWS_IAM
authentication for
internal APIs

67.
minimise function’s access

68.
requires developer discipline

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.
S3
AWS IoT
DynamoDB
RDS
EventStore
Elasticsearch Couchbase
Redshift
Neo4j
Google BigQuery

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

72.
leverage server-side encryption

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

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

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

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

77.
Least Privilege Principle

78.
Disposability is a virtue

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

80.
easier said than done…

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

82.
identifying ownership of
individual functions is
much harder

83.
tag every function with Team name

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

85.
more likely to scale through
DoS attacks

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

87.
configure WAF rules on
API Gateway and CloudFront

88.
review the default API Gateway
throttling settings

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.
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.
http://bit.ly/2v7F2E4

92.
DoS attack
2+ Retries+
?

93.
DoS attack
Regex DoS attack
long Lambda timeout
2+ Retries+
?

94.
avoid (unnecessary) long timeouts

95.
alert on error rate

96.
Day 1

97.
Day 2

98.
no long-lived compromised servers

99.
containers are reused, avoid
sensitive data in /tmp

100.
https://www.puresec.io/function-shield

101.
no accidentally exposed directories

102.
cryptojacking

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

104.
monitor activities in
unused regions using
CloudWatch Events

105.
set up billing alarms in unused regions

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

107.
Michael Nygard

108.
least privilege principle

109.
per function policies

110.
account level isolation

111.
Recap

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

113.
sanitise inputs and outputs

114.
Least Privilege Principle

115.
here’s your per function policy
NEXT!

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

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

118.
delete unused functions.

119.
DoS DoW*
* Denial of Wallet

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.
don’t be an unwilling bit miner

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

123.
prod dev
compartmentalise breaches

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

125.
@theburningmonk
theburningmonk.com
github.com/theburningmonk

126.
https://theburningmonk.com/hire-me
AdviseTraining Delivery