I created the baker's dozen of things to think about when migrating or deploying in AWS. Use comments to add your input. Read time approx. 15-20 minutes max. There is also a long form written version of this on https://blog.lacework.com.

1. .start

2. Bakers Dozen to Securing AWS

3. Dan Hubbard, Lacework

4. @dhubbard858

5. So, you are running in AWS?

6. AWS has amazing advantages….

7. Speed

8. Velocity

9. Auto-scale

10. They run the infrastructure.

11. And let you focus on your apps.

12. That is what matters.

13. But how do you secure all of this?

14. Think different.

15. It’s less about the castle and moat.

16. And more about automation.

17. scale.

18. visibility.

19. context.

20. And most importantly….

21. Shrinking your attack surface.

22. Minimizing mistakes.

23. And fitting security INTO your
architecture.

24. NOT in FRONT of it.

25. Where do we start?

26. Drive towards least-privilege
systems.

27. I know, you may not be there TODAY.

28. You may be migrating

29. Least Privilege is easier said than
done.

30. But it’s a destination you want to
drive to.

31. And if you have the luxury of starting
over.

32. then start with least privilege.

33. Start with templatized workload
configuration.

34. Terraform (multi-platform)

35. CloudFormation = AWS specific

36. Next select your orchestration
system.

37. Kubernetes

38. Docker Swarm

39. Mesos.

40. Choose your favorite container tech.

41. Likely Docker or equiv..

42. And finally your favorite OS.

43. CoreOS

44. Redhat

45. Ubuntu

46. OK, now let’s think about the
security...

47. Start with AWS Accounts.

48. Then your services

49. API’s

50. Compliance

51. Applications

52. Users

53. Secure your AWS account.1

54. Design your accounts carefully !

55. This is not easy to unwind and it’s
super important.

56. Balance accounts and
responsibilities.

57. Watch for sprawl.

58. You do not want to have too many
accounts.

59. If you have a reason for a LOT of
accounts.

60. Justify it !

61. Use AWS organizations.

62. MFA critical for all console
authentication.

63. Use instance roles for services.

64. Roles manage ephemeral keys
internally

65. CloudTrail2

66. Make sure it’s on for ALL accounts.

67. Log it in a place that you can query.

68. CloudTrail is very noisy

69. You need to understand the needles
in the data

70. Context is critical

71. Understand relevant change.

72. Change in config’s

73. Change in API usage

74. Change in critical services.

75. Change in user patterns.

76. Attackers can delete / turn off
CloudTrail

77. Segment S3 bucket with different
from monitored account

78. Secure Services3

79. EC2, S3, RDS, KMS...

80. Set a policy and a framework for
your services

81. Each service has unique attack
surface

82. How do you think about threats in
1000’s of services.

83. Lambda surface?

84. ECS ?

85. EKS ?

86. S3 ?

87. RDS ?

88. Redshift ?

89. Don’t boil the ocean YET.

90. Understand what you use, why, and
focus on those.

91. Learn what dev. is looking at next.

92. Compliance4

93. Your accounts and services need
continual checks

94. This is not your annual compliance
audit

95. Its all the time every time.

96. Start with CIS for AWS benchmarks

97. Expand into your relevant areas.

98. PCI

99. SOC II

100. HIPAA.

101. Secure the network.5

102. It’s not your network.

103. Yeah it’s virtual.

104. Limit what can go in and out.

105. Minimize in AND out.

106. Understand inter network traffic
(east-west)

107. But the network diminishes in
importance in cloud.

108. Like console access to the router

109. Firmare on edge router.

110. You don’t own it. Get used to that.

111. Network often static.

112. But systems are dynamic.

113. Containers and orchestration limit
relevance.

114. But monitor config’s still important
in VPC’s.

115. Secure the applications.6

116. What are they talking to?

117. And Why ?

118. Understand application topologies
and systems.

119. Gain insight into typical system
behavior

120. Understand outliers.

121. Log ALL application behaviors.

122. Abstract containers : translate apps :
containers : machines.

123. Did I mention log everything.

124. Ephemeral workloads must be
monitored

125. in near real-time.

126. Make meaning of the logs.

127. Good data turns into information
when it answers questions.

128. Who ran this app?

129. When did it run?

130. What did it do?

131. Where did it connect to?

132. Good data turns into information

133. when you either gain security
knowledge

134. or when your can answer questions
with context.

135. “Hey Dan, did you mean to install 50 new
GPU instances in the Europe Region running
Bitcoin Miners last night”?

136. Secure Users.7

137. Who can log into what machines.

138. Why?

139. Limit logins wherever you can!

140. Least Privileged systems.

141. If logins necessary….

142. NO SHARED ACCOUNTS

143. Unique accounts per user

144. Use MFA.

145. Setup a bastion.

146. 3 Factors of ID..

147. Setup VPN

148. Limit access via IP

149. Use IAM (oauth, SAML)

150. 3 Factors

151. Account password

152. Temporary password

153. And keys.

154. Log ALL logins.

155. Failures and Successes

156. Avoid service accounts logging in.

157. Yes no login as say...

158. ubuntu

159. coreos

160. admin

161. Or...root !!!!

162. Where possible limit users from
installing apps.

163. Immutable images.

164. Use the orchestration. That is what
its for.

165. Understand the app behaviors.

166. Both to from and to the Internet.

167. And laterally from application to
application.

168. Within your “network”

169. And from container to container.

170. Secure the Data.8

171. Encrypt it.

172. ALL OF IT.

173. Its likely someone will find value in
your data

174. Regardless of what you think.

175. Keys are critical.

176. Look into vaults.

177. Rotate.

178. Ephemeral keys

179. Layer 8 : People9

180. “DevSecOps”

181. It’s just a made up word.

182. Establish communication channel
from/to devops and security.

183. #Slack works.

184. Alert on criticals : PagerDuty or ?

185. Log criticals and below in #channel

186. Email still works too.

187. Retrospectives on alerts.

188. Get good at triage.

189. A great security product/system will
help bridge gaps

190. from developers to security

191. from security to developers.

192. within or across teams.

193. Best practices.10

194. There is no time continuum in
security.

195. It does not stop or start.

196. It is just part of the system

197. And the system needs testing.

198. Pen testing.

199. Vulnerability testing

200. It’s not as scary as it sounds.

201. War game with dev.

202. Think evil.

203. What if I had privileged access to ….

204. Think about.

205. Data exfil.

206. Data destruction.

207. Public disclosures.

208. Inadvertent configuration mistakes.

209. Compliance failures.

210. Low level bugs out of your control.

211. Ring0 happens.

212. Be prepared

213. For recovery

214. It’s not *if* the market will ask about
your security.

215. It’s *when*.

216. Have the answers before they ask.

217. But what about bugs in MY
applications?
11

218. Be responsible.

219. Follow responsible disclosures.

220. Answer security@yourdomain

221. Be friendly to bug hunters

222. Bug bounty not mandatory but look
into it.

223. Don’t be held hostage to hunters.

224. But be responsible.

225. They are saving your time, money,
and potentially losses.

226. Run your own internal bug program.

227. Hack a thons are great for this.

228. And finally….

229. Have fun.12

230. Be thankful.

231. You are designing the future state.

232. Starting over is a privilege.

233. Learn from past mistakes.

234. To determine the future.

235. Wait, bakers dozen!13

236. What do you feel is missing?

237. Add your comments here.

238. Share your experiences.

239. Give back to the community :)

240. Lacework : Let us run your security

241. Lacework : While you focus on your apps.

242. Dan Hubbard, Lacework

243. @dhubbard858

244. .end