Security for AWS: Journey to Least Privilege
0 likes102 views
The document provides a lengthy set of recommendations for securing applications and infrastructure running on AWS. It begins by emphasizing the importance of least privilege access and automation for security. It then covers specific recommendations around securing AWS accounts, services, compliance, networks, applications, users, and data. It stresses the importance of communication between security and development teams and following security best practices like penetration testing.
Security for AWS: Journey to Least Privilege
- 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