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.

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

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

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

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