Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Iterative Security: Secrets when you're not ready for Vault


Published on

At CloudZero we're a startup and getting started is better than someone's definition of being perfect. And in security, getting started will have the most impact on fortifying your security posture and allow you to eventually reach that desired state.

There are great tools out there for managing secrets. But the problem space is still hard and the tools require time and investment. Let's apply an iterative approach to solving secrets management. Let's take an organization one step to the right from no secrets management to a state that a) improves their current state and b) sets them up a future improvement iteration.

related content the spawned this presentation:

Published in: Internet
  • Be the first to comment

Iterative Security: Secrets when you're not ready for Vault

  1. 1. @tmclaughbos Iterative Security:
 Secrets Management When You’re Not Ready For Vault @tmclaughbos
  2. 2. @tmclaughbos Who is this guy up here? His headshot is lasers and a cat
  3. 3. @tmclaughbos I’m Tom! • Community Engineer at CloudZero • Previously infrastructure engineer with a focus on automation.
  4. 4. @tmclaughbos Background & Biases Where I’m coming from
  5. 5. @tmclaughbos Background & Biases: I like startups
  6. 6. @tmclaughbos Background & Biases: I like startups
  7. 7. @tmclaughbos Background & Biases: Engineering is just a title
  8. 8. @tmclaughbos Does this look like you?
  9. 9. @tmclaughbos There is a lot of work to be done each day
  10. 10. @tmclaughbos For many of us, this ends up as reality…
  11. 11. @tmclaughbos We have all this technology! So why does these problems still exist?
  12. 12. @tmclaughbos How we present security
  13. 13. @tmclaughbos Security Paralysis I don’t know what to do
  14. 14. @tmclaughbos Security things you in ops might end up responsible for • Access controls • How much is too much access? • Password policies • How often should I force password rotation? • Wait, NIST has changed their recommendation? Don’t force rotation? • Patching • Do I patch immediately on every vendor release or test first? • and more…
  15. 15. @tmclaughbos
  16. 16. @tmclaughbos I am not a “security person”
  17. 17. @tmclaughbos Iterative Security Starting and progressively improving your security stance
  18. 18. @tmclaughbos Why is security hard for us?
  19. 19. @tmclaughbos OMG SECURITY!!!
  20. 20. @tmclaughbos Things we get excited about with security
  21. 21. @tmclaughbos Things we get excited about with security 0-Days!!!
  22. 22. @tmclaughbos Things we get excited about with security Hash collisions
  23. 23. @tmclaughbos Things we get excited about with security What the CIA/NSA/DoD has
  24. 24. @tmclaughbos Things we get excited about in security Logos
  25. 25. @tmclaughbos Things we don’t get excited about with security
  26. 26. @tmclaughbos Patching!
  27. 27. @tmclaughbos Not leaving MongoDB exposed to the internet with weak credentials
  28. 28. @tmclaughbos Not leaving Elasticsearch exposed to the internet with weak credentials
  29. 29. @tmclaughbos Learning from our mistakes
  30. 30. @tmclaughbos Many of us focus on the wrong things
  31. 31. @tmclaughbos How we present security
  32. 32. @tmclaughbos What we should be teaching • What are you trying to do? • Where do you start? • How do you progress
  33. 33. @tmclaughbos There’s a lot of info at the extremes
  34. 34. @tmclaughbos But this is where many of us are
  35. 35. @tmclaughbos We know not to… Put passwords, API keys, tokens, etc. in code.
  36. 36. @tmclaughbos But it still happens…
  37. 37. @tmclaughbos Where do you go from here?
  38. 38. @tmclaughbos Developing a threat model!
  39. 39. @tmclaughbos Be Realistic
  40. 40. @tmclaughbos USB sticks are a bigger threat than the man in the ceiling
  41. 41. @tmclaughbos A breach probably won’t end business
  42. 42. @tmclaughbos What are we trying to protect? • Intellectual property • Customer data (data about who our customers are) • Customer’s data (data from our customers) • etc.
  43. 43. @tmclaughbos What does our architecture look like?
  44. 44. @tmclaughbos Decompose the system
  45. 45. @tmclaughbos Decompose system: Perimeters
  46. 46. @tmclaughbos Decompose system: Data pipeline
  47. 47. @tmclaughbos Decompose system: Data pipeline
  48. 48. @tmclaughbos Identify threats • Exposed network ports (network) • Unpatched EC2 instances (host) • Weak secrets management(application) • User submitted data (application) • etc.
  49. 49. @tmclaughbos Document Threats • Weak password management • At two points in our infrastructure we’re not managing passwords • Both points involve highly valuable assets • Breach would be bad • Reputation loss -> customer loss • Data could be leveraged against our customers
  50. 50. @tmclaughbos Rate Threats Risk = Probability * Damage Potential
  51. 51. @tmclaughbos Rate Threats • D: Damage potential • R: Reproducibility • E: Exploitability • A: Affected users • D: Discoverability
  52. 52. @tmclaughbos Rate Threats • D: Disaster if this is found (high) • R: Easy to reproduce (high) • E: Easy to exploit; requires existing access (medium) • A: Affects all users (high) • D: Not easy to find; users are hops away from issue (medium)
  53. 53. @tmclaughbos Putting a response into action Let’s manage those secrets
  54. 54. @tmclaughbos Constraints Time Complexity Risk
  55. 55. @tmclaughbos Constraints: Time
  56. 56. @tmclaughbos Constraints: complexity
  57. 57. @tmclaughbos Constraints: Risk of failure “It’s all code… We monitor it using Nagios.”
  58. 58. @tmclaughbos Constraints • Time: Few days to a few weeks • The faster we get this done the more likely we will finish. • Complexity: We’re going to go with what we know. • Less surprises. • Less to learn and get wrong. • Risk: Taking only as much risk as we’re ready for. • We’re moving fast! • Let’s limit the failure blast radius
  59. 59. @tmclaughbos Approaches to get you started Finally we secure some secrets
  60. 60. @tmclaughbos git-crypt • Encrypts secrets directly in your repository • Find secrets, rotate, and store them
  61. 61. @tmclaughbos git-crypt • Pro • You’ve done the exercise of auditing your code base • Cons • Symmetric encryption • Everyone needs the master password • TODO • Prevent key proliferation • Move to new secrets management when ready
  62. 62. @tmclaughbos Configuration Management: Puppet • Hiera-eyaml: Encrypt values in your Hiera hierarchy • Can use public key encryption • Multiple backends
  63. 63. @tmclaughbos Configuration Management: Puppet • Pros • You’ve centralized your secrets in one repo. • Public key encryption support • Cons • May require manual intervention when rolling Puppetmasters. • May need to cleanup your Puppet code if you haven’t already moved to Hiera. • TODO: • Figure out master rekey strategy
  64. 64. @tmclaughbos Configuration Management: Ansible • Ansible Vault: Encrypts entire var files in playbook
  65. 65. @tmclaughbos Configuration Management: Ansible • Pros • You’ve done the exercise of auditing your code base • Cons • Symmetric encryption • Everyone needs the shared password • key proliferation • TODO • Preventing the proliferation of the Vault key • rekeying and rolling secrets.
  66. 66. @tmclaughbos S3 Buckets • Sneaker • Encrypt, store, and retrieve secrets from S3.
  67. 67. @tmclaughbos S3 Buckets • Pros • Secrets no longer live in repos • reduced secret proliferation • Secrets encrypted in S3. • Cons • How are you managing S3 buckets? • TODO • Manage your S3 buckets with CloudFormation, Terraform, etc.
  68. 68. @tmclaughbos What should we have gotten out of all this?
  69. 69. @tmclaughbos Less this…
  70. 70. @tmclaughbos …More this!
  71. 71. @tmclaughbos YOU CAN DO THIS!
  72. 72. @tmclaughbos Thank You!
  73. 73. @tmclaughbos
  74. 74. @tmclaughbos Threat Modeling: startup edition
  75. 75. @tmclaughbos Threat Modeling: startup edition response
  76. 76. @tmclaughbos We know what not to do. We (think) we know where we want to be. But we don’t know how to get there.