Making Security Approachable for Developers and Operators
- 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 SUITEOSS TOOL SUITE RUN Applications SECURE Application Infrastructure PROVISION Infrastructure FOR INDIVIDUALS FOR TEAMS Nomad Enterprise
- 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
- 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? …
- 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 ApplicationTraffic 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