Slide 1

Slide 1 text

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

Slide 27

Slide 27 text

Application Concerns Existing Concerns SQL Injection XSS User Passwords Session Management Access Controls

Slide 28

Slide 28 text

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

Slide 34

Slide 34 text

Splitting the Problems Platform Layer Application Middleware Frameworks Application Logic Broad Reach Limited Reach

Slide 35

Slide 35 text

Platform Layer Platforms like K8S, Nomad, etc Lowest layer, and broadest reach Secret management AuthN / AuthZ of service traffic

Slide 36

Slide 36 text

Platform Layer Platform Layer Application Traffic Proxy Secrets Isolated Namespace Plaintext
 Traffic Plaintext
 Secrets Fetch Secrets Authenticated
 Authorized Encrypted Traffic (Mutual TLS)

Slide 37

Slide 37 text

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

Slide 53

Slide 53 text

Thanks! Twitter: @armon https://hashicorp.com