Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

SEC304 Building Security from Scratch - AWS re: Invent 2012

2 447 vues

Publié le

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.

SEC304 Building Security from Scratch - AWS re: Invent 2012

  1. 1. alex@artemis.net .secure and we are building it on AWS
  2. 2. Who shapes it?
  3. 3. Who is that? Cloud Providers Security Vendors Old Guard
  4. 4. Where is it?
  5. 5. What is it?
  6. 6. What is it? Very slow moving Created by non-technologists Defined in the age of traditional infrastructures REALITY!
  7. 7. 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
  8. 8. Bugs we’ve seen
  9. 9. Bugs we haven’t seen
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. “What do we have on the spacecraft that’s good?”
  14. 14. Sic Parvis Magna
  15. 15. C=E(P,Ks)C + {Ks}User1 + {Ks}GroupA+ {Ks}Service1 + {Ks}Master
  16. 16. 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
  17. 17. We are sincerely eager tohear your FEEDBACK on thispresentation and on re:Invent. Please fill out an evaluation form when you have a chance. alex@artemis.net