Making Security Approachable for
Developers and Operators
Slide 2
Slide 2 text
Armon Dadgar
Co-Founder and CTO, HashiCorp
@armon
Slide 3
Slide 3 text
PROVISION, SECURE AND RUN ANY INFRASTRUCTURE
Nomad Consul
Vault
Vagrant Packer Terraform
Consul Enterprise
Terraform Enterprise
Vault Enterprise
PRODUCT SUITE
OSS TOOL SUITE
RUN
Applications
SECURE
Application Infrastructure
PROVISION
Infrastructure
FOR INDIVIDUALS FOR TEAMS
Nomad Enterprise
Slide 4
Slide 4 text
Goal:
Make Security Approachable
Slide 5
Slide 5 text
Developer
“Security is approachable! I don’t think about it!”
Narrator: We want to make security approachable for our developers…
Slide 6
Slide 6 text
Security Mindset
Start with Security Model
Simplifying Assumptions
Transparent to developers
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
Castle & Moat Security
Network Perimeter Based
Traffic over ingress/egress filtered
Network middleware heavy
Firewalls, WAFs, SIEMs, etc.
Slide 9
Slide 9 text
Castle & Moat Mentality
Outside is adversarial and low trust
Inside is vetted and high trust
Network provides confidentiality and integrity
Slide 10
Slide 10 text
Division of Labor
Security Teams
Network Teams
Operation Teams
Developer Teams
Slide 11
Slide 11 text
Security Teams
Responsible for Policies and Rules
Firewall rules govern traffic flows
IP-based, millions of rules
Slide 12
Slide 12 text
Network Teams
Responsible for network topology
Must constrain traffic through middleware
Zone A Zone B
Slide 13
Slide 13 text
Operations Teams
Responsible for infrastructure and application
deployment
Must deploy to correct zone
Slide 14
Slide 14 text
Developer Teams
Responsible for application development
Security imposed at the network layer
Slide 15
Slide 15 text
What’s wrong?
Slide 16
Slide 16 text
Castle & Moat Model
Simplifying abstraction, not perfect
Make assumptions, which allow us to omit concerns
Slide 17
Slide 17 text
Consider: Insiders
Assumption: Insiders (employees, contractors, etc) are
all trustworthy and have good intent.
Real World: Insiders are not universally trustworthy,
and a major source of breaches and data exfiltration.
Insiders also subject fo phishing, malware, social
engineering, etc.
Slide 18
Slide 18 text
Consider: Network Integrity
Assumption: Network Perimeter is effective and lets
us assert an external low trust and internal high trust.
Real World: Perimeter is porous. Workstations and
mobile devices are connected via VPNs and corporate
fabrics. Software bugs lead to remote code execution
or attackers on box.
Slide 19
Slide 19 text
Castle & Moat in Practice
Real world does not match our assumptions
Assumptions were good enough for a while
Larger, more complex networks today
All-or-nothing vs defense-in-depth
Slide 20
Slide 20 text
Alternate Security Models
Slide 21
Slide 21 text
Zero Trust Model
Perimeter is 80% effective, not 100%
Do not trust the private network (or insiders)
Breaks our assumptions and approach
Demands more of applications
Slide 22
Slide 22 text
Secret Management
Secrets are sprawled everywhere in plaintext
Limited AuthN, AuthZ, and Audit of access
Zero Trust requires better hygiene
Centralized, Encrypted, Tightly Controlled
Applications need secrets!
Slide 23
Slide 23 text
Data Protection
Sensitive data written in plaintext to storage
Databases might use Transparent Disk Encrypt (TDE)
Protects against stealing a disk drive
Does not protect “SELECT * FROM CUSTOMERS”
Slide 24
Slide 24 text
Data Protection
Encrypt Data
Store Encrypt Data
Key Management
Crypto APIs
Databases
Data Warehouse
Application
Slide 25
Slide 25 text
Data Protection
Two factor compromise required
Keys cannot be exported or exfiltrated
Requires decryption to be done online
Strictly better than Transparent Disk Encryption
Slide 26
Slide 26 text
Traffic AuthN / AuthZ
Applications assumed network integrity / confidentiality
Not safe in Zero Trust model
Need caller identity (AuthN)
Need explicit caller authorization (AuthZ)
Applications network traffic must be encrypted for
confidentiality
Application Concerns
Existing Concerns
SQL Injection
XSS
User Passwords
Session Management
Access Controls
New Concerns
Secret Management
Data Protection
AuthN / AuthZ of RPCs
Traffic Encryption
Slide 29
Slide 29 text
Complexity of Security
Security is a deep and broad domain
Not very accessible to beginners
Language makes heavy use of jargon
Slide 30
Slide 30 text
Java 7: Cipher Class Documentation:
Slide 31
Slide 31 text
Java Documentation
What is a block cipher?
What is padding and why does it matter?
What is AEAD / Authenticated Encryption with Associated
Data?
What are modes? GCM, CBC, CCM, ECB?
What is an IV? How is it related to a nonce?
…
Slide 32
Slide 32 text
Approachable Security
Slide 33
Slide 33 text
Path Forward
Not reasonable to make developers security experts
Externalization of concerns
Specialization of labor
Practitioner Education
Application Middleware
Tools like HashiCorp Vault, Auth0, AWS KMS
Services with APIs
Key Management, Crypto APIs, User Passwords,
Data Protection
Slide 38
Slide 38 text
Vault for Cryptographic Offload
“Transit” backend, key management / crypto API
Define a named key
API for high level operations (encrypt, decrypt, random
bytes, etc)
Simple REST call
No knowledge of AES, GCM, IVs, etc. needed
Slide 39
Slide 39 text
Frameworks
Opinionated Frameworks (Rails, Django, etc)
Guard against common application logic issues
XSS, SQL Injection, Session Management, Access
Controls
Slide 40
Slide 40 text
Application Logic
Always vulnerable to logic bugs
Avoid re-inventing the wheel when possible
Consume APIs (middleware) and Libraries
(frameworks)
Safe languages to many classes of issues
Slide 41
Slide 41 text
Division of Labor
Security Teams
Network Teams
Operation Teams
Developer Teams
Slide 42
Slide 42 text
Security Teams
Responsible for Policies and Rules
Logical Service Rules (not Firewall Rules)
“Web Server to Database” not “IP1 to IP2”
Thousands vs Millions of Rules
Slide 43
Slide 43 text
Network Teams
Responsible for network topology
Traffic not constrained through middleware
Applications not assuming networking integrity
Slide 44
Slide 44 text
Operations Teams
Responsible for infrastructure and application
deployment
Provide facilities for secret management, data
protection, traffic filtering on endpoints
Slide 45
Slide 45 text
Developer Teams
Responsible for application development
Leverage frameworks, security middleware, and
platform features
Understand the threat model
Concerns externalized but not transparent
Slide 46
Slide 46 text
Practitioner Education
Specialization of labor
T-Shaped Specialists
Security language needs to be accessible
Slide 47
Slide 47 text
Teaching Security
Motivate the problems.
Mandate: Encrypt your data
Prompt: Consider if an attacker can reach the
database
Simple explanations
Descriptive power vs precision
Slide 48
Slide 48 text
Conclusion
Slide 49
Slide 49 text
Traditional Security
Castle & Moat / Perimeter Based
Based on simplifying assumptions that are wrong
Allowed developers to ignore many security concerns
Slide 50
Slide 50 text
Zero Trust
Zero Trust acknowledges perimeter is 80% effective
Network does not provide integrity or confidentiality
Requires secret management, data protection, service
segmentation
Slide 51
Slide 51 text
Growing Application Concerns
Developers already have many concerns (XSS, SQL
Inject, etc)
Lack of network trust adds even more to their plate
Impractical to assume deep security expertise
Slide 52
Slide 52 text
Involving and Scaling Developers
Security Aware / T-Shaped Practitioners
Zero Trust embedded into the Platform
Externalize to Frameworks, Services, and Platforms
Specialization of Labor
Practitioner-oriented education