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

Making Security Approachable for Developers and...

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
Tweet

More Decks by Armon Dadgar

Other Decks in Technology

Transcript

  1. 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
  2. Developer “Security is approachable! I don’t think about it!” Narrator:

    We want to make security approachable for our developers…
  3. Castle & Moat Security Network Perimeter Based Traffic over ingress/egress

    filtered Network middleware heavy Firewalls, WAFs, SIEMs, etc.
  4. Castle & Moat Mentality Outside is adversarial and low trust

    Inside is vetted and high trust Network provides confidentiality and integrity
  5. 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.
  6. 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.
  7. 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
  8. 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
  9. 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!
  10. 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”
  11. Data Protection Two factor compromise required Keys cannot be exported

    or exfiltrated Requires decryption to be done online Strictly better than Transparent Disk Encryption
  12. 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
  13. 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
  14. Complexity of Security Security is a deep and broad domain

    Not very accessible to beginners Language makes heavy use of jargon
  15. 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? …
  16. Path Forward Not reasonable to make developers security experts Externalization

    of concerns Specialization of labor Practitioner Education
  17. Platform Layer Platforms like K8S, Nomad, etc Lowest layer, and

    broadest reach Secret management AuthN / AuthZ of service traffic
  18. Platform Layer Platform Layer Application Traffic Proxy Secrets Isolated Namespace

    Plaintext
 Traffic Plaintext
 Secrets Fetch Secrets Authenticated
 Authorized Encrypted Traffic (Mutual TLS)
  19. Application Middleware Tools like HashiCorp Vault, Auth0, AWS KMS Services

    with APIs Key Management, Crypto APIs, User Passwords, Data Protection
  20. 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
  21. Frameworks Opinionated Frameworks (Rails, Django, etc) Guard against common application

    logic issues XSS, SQL Injection, Session Management, Access Controls
  22. 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
  23. 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
  24. Network Teams Responsible for network topology Traffic not constrained through

    middleware Applications not assuming networking integrity
  25. Operations Teams Responsible for infrastructure and application deployment Provide facilities

    for secret management, data protection, traffic filtering on endpoints
  26. Developer Teams Responsible for application development Leverage frameworks, security middleware,

    and platform features Understand the threat model Concerns externalized but not transparent
  27. Teaching Security Motivate the problems. Mandate: Encrypt your data Prompt:

    Consider if an attacker can reach the database Simple explanations Descriptive power vs precision
  28. Traditional Security Castle & Moat / Perimeter Based Based on

    simplifying assumptions that are wrong Allowed developers to ignore many security concerns
  29. Zero Trust Zero Trust acknowledges perimeter is 80% effective Network

    does not provide integrity or confidentiality Requires secret management, data protection, service segmentation
  30. 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
  31. 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