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
Tweet

More Decks by Armon Dadgar

Other Decks in Technology

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