Alex Stamos CTO, Artemis Internet Building Cloud Security from Scratch
Nov 07, 2014
Alex StamosCTO, Artemis Internet
Building Cloud Security from Scratch
What are we discussing today?
• Discuss the state of cloud security conventional wisdom
• Identify why that doesn’t work
• Think about how to build trust into our infrastructures…
FROM SCRATCH
Who am I?
Alex [email protected]
• Co-Founder of iSEC Partners• CTO of Artemis Internet
We are building .secureand we are building it in the cloud
Conventional WisdomWho shapes it?
The current keeper of the CW is the:
Conventional WisdomWho is that?
Cloud Providers Security Vendors Old Guard
Conventional WisdomWhere is it?
This wisdom is captured best here:
Conventional WisdomWhat is it?
Conventional WisdomWhat is it?
Compliance Model
Security Controls Model
Cloud Model
Very slow moving
Created by non-technologists
Defined in the age oftraditional infrastructures
REALITY!
Conventional WisdomWhere does it go wrong?
Web VLAN
Load Balancers
Web Servers
App Server VLANApp Servers
DB VLAN
Corporate Network
Support VLAN
Backup SNMP
Logging Bastion
Internet
LBsHow would attackers penetrate this network in 1998?
How about today?
Getting RealBugs we’ve seen
Operational
Lost Credentials
Overly Permissive Controls
Bad Auditing
Infrastructure
Poor Patching
Insecure Control Plane
Attacks from Corp
Application
Too-Loose Binding
Web/API Vulns
Bad Crypto
Getting RealBugs we haven’t seen
Fantasy Issues
Hypervisor Breaks
Covert Channels/Timing Attacks
Physical Breaches
Getting RealControls that match real risks
Operational
Lost Credentials
Overly Permissive Controls
Bad Auditing
• 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
Getting RealControls that match real risks
Infrastructure
Poor Patching
Insecure Control Plane
Attacks from Corp
• 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
Getting RealControls that match real risks
Application
Too-Loose Binding
Web/API Vulns
Bad Crypto
• 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
Cloud Strengths“What do we have on the spacecraft that’s good?”
Architecture and design benefits:• Out-of-band bootstrapped communication• Isolated network topologies (VPC)• Trusted 10.x space IPs
Defense against privileged cloud accounts:• Instance RAM• Ephemeral per-instance storage
Cloud StrengthsSic Parvis Magna
UserData
Protected Instance Memory
Key Management Service
Crypto Keys
Encrypted MQ Messages
Encrypted DB Records
Encrypted EBS Volume
Service Creds
IPSec PSK
Secure Instance-Instance Network
Trustworthy Source IPs
Architecting a Paranoid Application
App ServerELB
Authentication Service
Cred DB
Back-End Service
Back-End Service
User Data
Blob Store
App ServerApp ServerApp Server
Logging System
[ ]The Authentication Token
• Primary Key• GUID
• Email• Real Name• Org ID
• Envelope Opening Key
• Group Membership• Admin Level• Perm Bits
Identity Context
Crypto KeysPermissions
AuthServer
Per-Record Crypto
P = Plaintext Record for User1, member of GroupAC = CiphertextKs = Per-Record Symmetric Key
C=E(P,Ks)
Data Record = C + {Ks}User1 + {Ks}GroupA+ {Ks}Service1 + {Ks}Master
Conclusions
1. Do not trust the conventional wisdom
2. Consider realistic threats for your org, adversaries
3. Build controls based upon AWS’s strengths
4. Build a paranoid application on any platform
Thank you for your [email protected]