Building Cloud Security from Scratch


Published on

Ask any two cloud "experts" about whether you can trust cloud providers for running your security sensitive systems and you'll likely get three opinions. When our group of security experts turned to the task of building a robust, reliable, and secure infrastructure, we chose to disregard the conventional wisdom, ignore the FUD, and design controls that allow us to confidently build on AWS, Salesforce, and other cloud providers. This talk walks you through the steps necessary to build a trustworthy cloud infrastructure. We outline how you can deconstruct your security needs into specific technical goals, map those goals onto controls that are available in the cloud, and discuss what risks need to be accepted while others are mitigated. The talk includes detailed discussion of cryptographic, network and logical controls, and is best enjoyed by those with advanced knowledge of AWS.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building Cloud Security from Scratch

  1. 1. Alex StamosCTO, Artemis Internet
  2. 2. .secure and we are building it in the cloud
  3. 3. Who shapes it?
  4. 4. Who is that? Cloud Providers Security Vendors Old Guard
  5. 5. Where is it?
  6. 6. What is it?
  7. 7. What is it? Very slow moving Created by non-technologists Defined in the age of traditional infrastructures REALITY!
  8. 8. InternetWhere does it go wrong? LBs Load Balancers Corporate Network Web VLAN Web Servers Backup SNMP Support VLAN Logging Bastion App Server VLAN App Servers DB VLAN
  9. 9. Bugs we’ve seen
  10. 10. Bugs we haven’t seen
  11. 11. Controls that match real risks • Limited accounts via IAM • Keep powerful creds off of instances • Use key managers to distribute creds, not on AMIs • Use limited accounts from Day 1 • MFA on top-level accounts • Limit direct access, use management platforms when possible • Use multiple top-level accounts with shared billing • No developers on production • Require all access via bastion host • Log every keystroke, all syslog to separate top-level account
  12. 12. Controls that match real risks • Continuous external and semi-external scanning • Auto-discover all instances via API • Use highly limited AMIs, install or chroot major services • Build control plane and asymmetric trust into AMI • Avoid SSH keys in AMI • SSH key per admin, revocable • Deploy corporate controls: • Proxy or DPI firewall • NFR • Use VPCs to strongly isolate critical services
  13. 13. Controls that match real risks • Security is a targeted feature • Create security engineering group early • Build small set of trusted, core components • Input validation • Escaping on compositing • Session management • Crypto • Build a separate, protected authentication cluster • Use self-proving requests internally, do not trust caller blindly • Provision internal certs to all instances, use when possible
  14. 14. “What do we have on the spacecraft that’s good?”
  15. 15. Sic Parvis Magna
  16. 16. C=E(P,Ks)C + {Ks}User1 + {Ks}GroupA+ {Ks}Service1 + {Ks}Master
  17. 17. 1. Do not trust the conventional wisdom2. Consider realistic threats for your org, adversaries1. Build controls based upon AWS’s strengths2. Build a paranoid application on any platform
  18. 18.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.