Making Security Approachable for Developers and Operators

Security is a complex topic filled with jargon and subtle nuances. The "weakest link" challenge in security means we must be concerned with every threat vector and apply best practices universally. This becomes challenging when we need to bring developers and operators into the fold, since our infrastructure and applications are critical to the our security posture. Instead of expecting everybody to become an expert in security, we need to make security more approachable for these audiences. In this talk, we discuss how to apply best practices and make them accessible to developers and operators through APIs, secure by default platforms, and policy as code.

Transcript

1. Making Security Approachable for Developers and Operators
2. Armon Dadgar Co-Founder and CTO, HashiCorp @armon
3. 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
4. Goal: Make Security Approachable
5. Developer “Security is approachable! I don’t think about it!” Narrator: We want to make security approachable for our developers…
6. Security Mindset Start with Security Model Simplifying Assumptions Transparent to developers
8. Castle & Moat Security Network Perimeter Based Traffic over ingress/egress filtered Network middleware heavy Firewalls, WAFs, SIEMs, etc.
9. Castle & Moat Mentality Outside is adversarial and low trust Inside is vetted and high trust Network provides confidentiality and integrity
10. Division of Labor Security Teams Network Teams Operation Teams Developer Teams
11. Security Teams Responsible for Policies and Rules Firewall rules govern traffic flows IP-based, millions of rules
12. Network Teams Responsible for network topology Must constrain traffic through middleware Zone A Zone B
13. Operations Teams Responsible for infrastructure and application deployment Must deploy to correct zone
14. Developer Teams Responsible for application development Security imposed at the network layer
15. What’s wrong?
16. Castle & Moat Model Simplifying abstraction, not perfect Make assumptions, which allow us to omit concerns
17. 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.
18. 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.
19. 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
20. Alternate Security Models
21. 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
22. 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!
23. 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”
24. Data Protection Encrypt Data Store Encrypt Data Key Management Crypto APIs Databases Data Warehouse Application
25. Data Protection Two factor compromise required Keys cannot be exported or exfiltrated Requires decryption to be done online Strictly better than Transparent Disk Encryption
26. 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
27. Application Concerns Existing Concerns SQL Injection XSS User Passwords Session Management Access Controls
28. 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
29. Complexity of Security Security is a deep and broad domain Not very accessible to beginners Language makes heavy use of jargon
30. Java 7: Cipher Class Documentation:
31. 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? …
32. Approachable Security
33. Path Forward Not reasonable to make developers security experts Externalization of concerns Specialization of labor Practitioner Education
34. Splitting the Problems Platform Layer Application Middleware Frameworks Application Logic Broad Reach Limited Reach
35. Platform Layer Platforms like K8S, Nomad, etc Lowest layer, and broadest reach Secret management AuthN / AuthZ of service traffic
36. Platform Layer Platform Layer Application Traffic Proxy Secrets Isolated Namespace Plaintext
 Traffic Plaintext
 Secrets Fetch Secrets Authenticated
 Authorized Encrypted Traffic (Mutual TLS)
37. Application Middleware Tools like HashiCorp Vault, Auth0, AWS KMS Services with APIs Key Management, Crypto APIs, User Passwords, Data Protection
38. 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
39. Frameworks Opinionated Frameworks (Rails, Django, etc) Guard against common application logic issues XSS, SQL Injection, Session Management, Access Controls
40. 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
41. Division of Labor Security Teams Network Teams Operation Teams Developer Teams
42. 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
43. Network Teams Responsible for network topology Traffic not constrained through middleware Applications not assuming networking integrity
44. Operations Teams Responsible for infrastructure and application deployment Provide facilities for secret management, data protection, traffic filtering on endpoints
45. Developer Teams Responsible for application development Leverage frameworks, security middleware, and platform features Understand the threat model Concerns externalized but not transparent
46. Practitioner Education Specialization of labor T-Shaped Specialists Security language needs to be accessible
47. Teaching Security Motivate the problems. Mandate: Encrypt your data Prompt: Consider if an attacker can reach the database Simple explanations Descriptive power vs precision
48. Conclusion
49. Traditional Security Castle & Moat / Perimeter Based Based on simplifying assumptions that are wrong Allowed developers to ignore many security concerns
50. Zero Trust Zero Trust acknowledges perimeter is 80% effective Network does not provide integrity or confidentiality Requires secret management, data protection, service segmentation
51. 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
52. 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
53. Thanks! Twitter: @armon https://hashicorp.com