Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Making Security Approachable for Developers and Operators

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.


Armon Dadgar

October 12, 2018

More Decks by Armon Dadgar

Other Decks in Technology


  1. Making Security Approachable for Developers and Operators

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


    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

  7. None
  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

  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

 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

  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