This document discusses how DevOps practices can sometimes break traditional security and compliance practices, and proposes an approach called SecDevOps 2.0 to better integrate the two. It outlines how SecDevOps 2.0 would define policies, identities, and networks in a way that supports continuous delivery while maintaining security and compliance. Key elements include defining security policies in code, using machine identities at scale for access control, and implementing new tools like secrets as a service and software-defined firewalls. The overall goal is to make security controls more transparent and integrated with automation.

1. Is DevOps Braking
Your Company?
Elizabeth Lawler
CEO & Co-Founder, Conjur, Inc.
@elizabethlawler

2. Agenda
I. Security + DevOps Recap
DevOps as a transformation
DevOps Workflow
Unstoppable Force vs Immovable
Object
Wrong Tools for the Job
II. SecDevOps 2.0: Defined
Motivation and Requirements
Policy, Identity and Network 2.0
Best Practices
III. SecDevOps 2.0: In Practice
New Tools
Case Study
Takeaways
IV. Q&A
Thank you!

3. Top Takeaways
1) Start conversations with all the stakeholders to
address current security and compliance
challenges
2) Map security and compliance best practice and
principles into continuous delivery
3) Expect this to be iterative and evolving process

4. I. Security + DevOps Recap

5. How does DevOps
work?
Magic.
How does DevOps
work?
Magic.

6. Security and Compliance Concerns : DevOps
Source: DevOps: The Worst-Kept Secret to Winning in the Application Economy by CA Technologies, October
2014 (http://rewrite.ca.com/us/~/media/rewrite/pdfs/white-papers/devops-winning-in-application-economy.pdf)
These are cultural
challenges with a
technical component.

7. Q: Is DevOps Breaking Your Company?
A: No, but security may break (or brake)
your DevOps!
DevOps leverages a set of tools and processes that
are constantly striving to go faster to meet business
needs.
Some DevOps tools/processes don’t easily lend
themselves to existing information security best
practices.

8. We’re All In It Together

9. Start The Conversation!
● Security, Compliance, Developers, and Operations
need personal relationships and mutual understanding.
● Differences in language: The way that security,
compliance, developers and ops talk about the same
problem can be bridged.
● Transparency and clear understanding of security
topology is good for the entire organization

10. II. SecDevOps 1.0
Duct Tape and Bailing Wire

11. DevOps is : Continuous Delivery
Dev, Test, & Prod
Environments
Code Review
Infrastructure
Source Code
Infrastructure
Code Developer
deploy
Continuous
Build & Unit
Test
Config, Release,
Deployment
commit on branch build
check
approval
tests pass
Holistic, Automated Processes
To Build And Deliver Software/IT Infrastructure

12. Let’s Create : Continuous Compliance
● Robust security and
compliance controls
… with
● Full support for
automation

13. SecDevOps 1.0: Where Are We Today?
Source Control
Automated Build and Test
Configuration Management
Orchestration
Software-Defined Networking
Monitoring

14. Continuous Delivery
● Code is the new privileged user/sys admin
● Who and what can touch the code is critical to
security
● Fewer people → more trusted services
● Machine identity and trust is critical
● Automation is a Force Multiplier and a
Double- Edged Sword
● Good: Patch management
● Bad: Vulnerability “globally” at the speed of light
● Ugly: Catastrophic failure

15. Continuous Delivery: Compliance Issues
Lack of transparency is the #1
obstacle to compliance
● Policies are buried in code
● Security for automation is ill-
defined
● Realtime reporting of controls
can be piecemeal
The User Experience is Lousy

16. Tools Are Being Pushed Beyond Their
Intended Function
“Sometimes when all you have is a
hammer, everything looks like a nail.”
● SCM: Collaboration, not least
privilege
● CI: Powerful system accounts
● Configuration Management
(Puppet/Chef): not secrets
management

17. Anti-Pattern: Production-only Workflows
Problem: Security controls
that developers cannot
replicate locally
Result: Speed-killer

18. Anti-Pattern: Human Bottlenecks
Problem: Security controls that
require manual intervention for
routine tasks
Result: Tech resources are
wasted on trivial tasks, unclear
organizational ownership of
tasks, throughput suffers, and
so does morale.
“Cool” DIY security projects become albatrosses

19. Anti-Pattern: Conflation of Concerns

20. Example : Mastering Secrets in Configuration
Management
Two orthogonal concerns:
1. Install packages and establish
configuration settings.
2. “Wire up” the system with identity
and secrets.
System “wiring” should not be
in the domain of configuration
management.

21. Anti-patterns create “Security Debt”
DevOps addressing security bottlenecks and issues are
often deferred, until…
New Product Feature New Security Feature

22. Worst-Case Scenario? Full Stop
● Regulated Workloads Aren’t
brought into the DevOps workflow
● Security Incident
o Breach or unauthorized
access because of workflow
challenges in getting the job
done
● Static Workflow Caps Velocity
o Changing is too hard or too
risky
o Toolchain

23. III. SecDevOps Version 2

24. SecDevOps 2.0: High-Level Goals
1. Code is the new “Privileged User”
2. Scale-out with granular permissions management
3. Highly durable and scalable - like cloud infrastructure
itself
4. Make the brakes as powerful as the engine

25. Challenges in mapping the organization
to dynamic infrastructure:
● Practical Separation of Duties
● Least Privilege Access via Role-
Based Access Control
● Audit and Reporting
Application Auth
Systems Access
Internal Network
Physical Infrastructure
Firewall
Control Plane
Mind The Gap: Access Control for Automation

26. Works with automation
Supports agile development and continuous delivery
Is intuitive to security and compliance teams
We Need To Rethink How We Define
Policies, Identities And Networks In A
Way That...

27. DevOps = Code = Security In Source Control
Security setup should be declarative in code.
1. Visible to all teams that depend on security.
2. Resolves confusion around where things are, what they
are named, who/what has access to what.
3. Changes to topology are versioned and can be
reviewed.
4. At Run-Time : Code is privileged, Secrets are injected

28. SecDevOps 2.0: Security Policy As Code
dev
prod
stage
Conjur Policy DSL

29. SecDevOps 2.0: Identity For Machines At Scale
● Each Server (VM), Container
(Docker, LXC) and Service
needs to have an identity for
access control to be
meaningful
● Provisioning of these
identities needs to be
automated and included in
SecDevOps workflow
● Machine-to-machine trust

30. New Tools: Identity Management For
Robots
Machine trust and identity that works for
servers, VMs, containers, and IOT.
Apply known tools and techniques from
traditional identity management to robots
Example: Segregation of regulated
applications/cloud into distinct application
layers using policies that govern each
service

31. Identity: Benefits For Access Control
Ops
Dev Group 1
Dev Group 2
App
1
App
2
App
3
App
4● Identities provisioned at a granular
level allow for the creation of
meaningful authorization policy
● Machine identities can be grouped
into applications or environmental
layers to simplify policy creation
● “Carbon Identities” can also be
organized into groups and have
their access limited to certains sets
of machine identities

32. Opportunities To Improve Practices
● Provide a facility outside of operational tools to
access/include sensitive information.
● Create multiple environments organized by risk.
● Audit everything, including automation exceptions (one-
off builds).

33. New Tools : Secrets as a Service
Chef node
?
?
SecDevOps 1.0
✱ decryption keys are
secrets themselves
✱ key storage and retrieval
is complicated
✱ one decryption key per
node
✱ access logs difficult to
search and manage
✱ chef-vault makes key
distribution easier at the
expense of auto-scaling
SecDevOps 2.0
Chef node
✱ Nodes have an identity,
use that to fetch secrets.
Easily given and revoked
✱ Permissions are role-
based, applied to layers not
hosts
✱ Chef library encapsulates
authenticated HTTPS call
✱ full audit log of changes
https
RESTful
API
audit log

34. New Tools: Software-Defined Firewall
X

35. New Tools : Control Plane Microservices
● Delegate routine tasks to trusted microservices that are
governed by highly limited access control policies and
continuously audited
● Use Foundation/Golden Images to “bake in” trust in core
services, such as identity management, configuration
management, secrets-as-a-service and audit

36. Result: Clear Controls And Processes
Problem:
Solution:

37. Takeaways
1) Start conversations with all the stakeholders to
address current security and compliance
challenges
2) Map security and compliance best practice and
principles into continuous delivery
3) Expect this to be iterative and evolving process

38. IV. Q & A

39. Thank You!
Additional Questions? Connect...
Elizabeth Lawler
● email: elawler@conjur.net
● phone: (617) 906-8216
● web: www.conjur.net
● twitter: @elizabethlawler /@conjurinc