Security for AWS : Journey to Least Privilege (update)
- 1. .start
- 2. Bakers Dozen to Securing AWS
- 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.
- 21. Shrinking your attack surface.
- 23. And fitting security INTO your architecture.
- 24. NOT in FRONT of it.
- 25. Where do we start?
- 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.
- 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.
- 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.
- 58. You do not want to have too many accounts.
- 59. If you have a reason for a LOT of accounts.
- 60. Justify it !
- 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
- 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.
- 112. But systems are dynamic.
- 113. Containers and orchestration limit relevance.
- 114. But monitor config’s still important in VPC’s.
- 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!
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 236. What do you feel is missing?
- 237. Add your comments here.
- 239. Give back to the community :)
- 240. Lacework : Let us run your security
- 241. Lacework : While you focus on your apps.
- 243. @dhubbard858
- 244. .end