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.

3. alex@artemis.net
.secure
and we are building it on AWS

4. Who shapes it?

5. Who is that?
Cloud Providers Security Vendors Old Guard

6. Where is it?

7. What is it?

8. What is it?
Very slow moving
Created by non-technologists
Defined in the age of
traditional infrastructures
REALITY!

9. Internet
Where 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

10. Bugs we’ve seen

11. Bugs we haven’t seen

12. 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

13. 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

14. 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

15. “What do we have on the spacecraft that’s good?”

16. Sic Parvis Magna

19. C=E(P,Ks)
C + {Ks}User1 + {Ks}GroupA+ {Ks}Service1 + {Ks}Master

20. 1. Do not trust the conventional wisdom
2. Consider realistic threats for your org, adversaries
1. Build controls based upon AWS’s strengths
2. Build a paranoid application on any platform

21. We are sincerely eager to
hear your FEEDBACK on this
presentation and on re:Invent.
Please fill out an evaluation
form when you have a
chance.
alex@artemis.net