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
   

   View Slide

2. Armon Dadgar
   Co-Founder and CTO, HashiCorp
   @armon
   

   View Slide

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
   

   View Slide

4. Goal:
   Make Security Approachable
   

   View Slide

5. Developer
   “Security is approachable! I don’t think about it!”
   Narrator: We want to make security approachable for our developers…
   

   View Slide

6. Security Mindset
   Start with Security Model
   Simplifying Assumptions
   Transparent to developers
   

   View Slide

7. View Slide

8. Castle & Moat Security
   Network Perimeter Based
   Traffic over ingress/egress filtered
   Network middleware heavy
   Firewalls, WAFs, SIEMs, etc.
   

   View Slide

9. Castle & Moat Mentality
   Outside is adversarial and low trust
   Inside is vetted and high trust
   Network provides confidentiality and integrity
   

   View Slide

10. Division of Labor
    Security Teams
    Network Teams
    Operation Teams
    Developer Teams
    

    View Slide

11. Security Teams
    Responsible for Policies and Rules
    Firewall rules govern traffic flows
    IP-based, millions of rules
    

    View Slide

12. Network Teams
    Responsible for network topology
    Must constrain traffic through middleware
    Zone A Zone B
    

    View Slide

13. Operations Teams
    Responsible for infrastructure and application
    deployment
    Must deploy to correct zone
    

    View Slide

14. Developer Teams
    Responsible for application development
    Security imposed at the network layer
    

    View Slide

15. What’s wrong?
    

    View Slide

16. Castle & Moat Model
    Simplifying abstraction, not perfect
    Make assumptions, which allow us to omit concerns
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

20. Alternate Security Models
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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”
    

    View Slide

24. Data Protection
    Encrypt Data
    Store Encrypt Data
    Key Management
    Crypto APIs
    Databases
    Data Warehouse
    Application
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

29. Complexity of Security
    Security is a deep and broad domain
    Not very accessible to beginners
    Language makes heavy use of jargon
    

    View Slide

30. Java 7: Cipher Class Documentation:
    

    View Slide

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?
    …
    

    View Slide

32. Approachable Security
    

    View Slide

33. Path Forward
    Not reasonable to make developers security experts
    Externalization of concerns
    Specialization of labor
    Practitioner Education
    

    View Slide

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

    View Slide

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

    View Slide

36. Platform Layer
    Platform Layer
    Application
    Traffic Proxy
    Secrets
    Isolated Namespace
    Plaintext

    Traffic
    Plaintext

    Secrets
    Fetch Secrets
    Authenticated

    Authorized
    Encrypted
    Traffic
    (Mutual TLS)
    

    View Slide

37. Application Middleware
    Tools like HashiCorp Vault, Auth0, AWS KMS
    Services with APIs
    Key Management, Crypto APIs, User Passwords,
    Data Protection
    

    View Slide

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
    

    View Slide

39. Frameworks
    Opinionated Frameworks (Rails, Django, etc)
    Guard against common application logic issues
    XSS, SQL Injection, Session Management, Access
    Controls
    

    View Slide

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
    

    View Slide

41. Division of Labor
    Security Teams
    Network Teams
    Operation Teams
    Developer Teams
    

    View Slide

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
    

    View Slide

43. Network Teams
    Responsible for network topology
    Traffic not constrained through middleware
    Applications not assuming networking integrity
    

    View Slide

44. Operations Teams
    Responsible for infrastructure and application
    deployment
    Provide facilities for secret management, data
    protection, traffic filtering on endpoints
    

    View Slide

45. Developer Teams
    Responsible for application development
    Leverage frameworks, security middleware, and
    platform features
    Understand the threat model
    Concerns externalized but not transparent
    

    View Slide

46. Practitioner Education
    Specialization of labor
    T-Shaped Specialists
    Security language needs to be accessible
    

    View Slide

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
    

    View Slide

48. Conclusion
    

    View Slide

49. Traditional Security
    Castle & Moat / Perimeter Based
    Based on simplifying assumptions that are wrong
    Allowed developers to ignore many security concerns
    

    View Slide

50. Zero Trust
    Zero Trust acknowledges perimeter is 80% effective
    Network does not provide integrity or confidentiality
    Requires secret management, data protection, service
    segmentation
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide