The document discusses DevSecOps principles for delivering products continuously while maintaining security and compliance. It advocates treating security and compliance as engineering problems and integrating them into development practices like infrastructure as code, continuous delivery, monitoring and learning from failures. The document describes how one company implemented DevSecOps practices like secure software supply chains, automated security testing in CI/CD pipelines, monitoring and incident response to achieve security compliance and pass audits while maintaining continuous delivery of features.

1. DevSecOps
Security and Compliance at the Speed of
Continuous Delivery
Dag Rowe - OWASP Ottawa Sept 2018
@dagrowe

2. Holy Grails
You want to deliver product
You want to deliver it fast
You want people to trust it

4. Holy Grails
Oh and …
Usable, secure, has defense in
depth,
hardened, easy to patch, uses the
principle of least privilege, compliant,
auditable, supportable, uses modern tech,
attracts developers, cost effective ...

5. Holy Grails
And …
Still deliver features, GO!

7. Compliance
Document what you do
Do it
Prove you did it

9. Compliance
Document what you do
– Security Controls, plans, and processes
Do it
– Hard
Prove you did it
– If you haven’t planned - this can be hard,
disruptive work

10. Also ...

11. Can we move to
Compliance Engineering?

12. DevSecOps
Yes!
Treat the problem of security and
compliance as a test, release, and
observability engineering problem

13. Why focus on
Compliance?

15. Why Compliance?
Compliance opens wallets
Moves security spending from fear
• Avoid a big incident
To greed
• A sales tool
Paraphrasing Bruce
Schneier

17. DevSecOps
DevOps used to deliver and run systems in a
secure and reliable way
Bringing in Security and Compliance
increases the focus on Ops
– “You build it, you run it”

19. No Magic
Just DevOps done right
Other terms
– DevSecOps
– DevOpsSec
– Rugged DevOps
It is a good search phrase, tho

20. Enter the Dragon Tehama

21. tehama.io

22. Tehama the Product
Delivers privileged technical services
over the internet with
– Transparency
– Security
– Auditability
Ensures trust while enabling quick
onboarding and connectivity

24. Tehama and SOC2
Decided that SOC2 compliance was
mandatory
– Sales tool
– Trust tool
• Validated security practices via a
trusted 3rd party auditor

26. DevSecOps - Secret Sauce
The whole team approach
Leverage security and compliance expertise
in building out the system
Leverage the technical expertise of your
DevOps team
What about - Product? Testing? Marketing? Legal?
• Yes, the whole team

27. They are all stakeholders in delivery

28. Tehama DevSecOps Principles
Security and Compliance is not the office of
no
Build security in
Don’t be compliant for compliance’s sake
– Make it secure, to demonstrate
compliance
– Keep it valuable

29. *
* Respected Colleague

30. Implementation
Security is everyone’s job, all the time
Design it into the system
• Then it is just how the software is
delivered
Audit evidence is generated during daily
work
– Not extra work

31. DevOps Patterns
Infrastructure as Code
Continuous Delivery
Continuous Monitoring
Learning from Failure
Collaborative Culture

32. Policy Designed for CI/CD
Change Management
Standard Change
– Pre-approved
– Move most changes here
– High success rate, low MTTR
High Risk Change
– Classic security approval
Emergency Change
– Post release approval
– Don’t block an emergency change

34. DevOps Audit Defense
d) Automated security testing of the code and environment
is performed as part of the deployment pipeline, as per
CS2.e.
e) All production deployments must have a JIRA ticket
number. Deployers must input the JIRA ticket number into
the Jenkins build pipeline system for code to be deployed
into production.
i) Jenkins uses the JIRA plugin to pull information from
JIRA to include with the build information and push
information about the build into the JIRA ticket.

35. Implementation
Secure software supply chain
All images and OSs are from trusted repos
– Hardened
All software dependencies are scanned
Patch management is just another change

36. Implementation - SDLC
The SDLC is based on a CI/CD pipeline
Automatic
SAST
– Static Application Security Testing
DAST
– Dynamic Application Security Testing
SCA
– Software Component Analysis
Container vulnerability analysis

37. Implementation - SDLC
Manual
Prioritization and planning
Pull requests and code review
– Code review guidelines call out security
concerns with a standard checklist
PR approval, and release authorization

38. Implementation - Monitoring
Vulnerability plan includes intrusion detection
Requires monitoring and alerting to detect
incidents
• Alerting will launch Incident Response (IR)
• Note, manual detection is still in scope
– Strange system behaviour
– Customer reports
– AWS security
– Law enforcement

39. Implementation - IR and Logging
DevOps includes a focus on monitoring and
observability
• This is adds big value
• Enables robust Incident Response and
troubleshooting capabilities

40. Where’s the Evidence?
• Agile planning
• Work ticket workflow
– Pull requests
• CI/CD scan logs
– Remediation tickets
• Release ticket workflow
– Authorization
• Production monitoring
• Incident tickets
• Chat Ops
• Blameless post-mortems
– Remediation tickets

41. Results
Last pentest had no findings
Security and compliance dev work is not exceptional
First audit (Type 1) passed without complications
– Kudos from auditors
Second audit (Type 2) had no major out of band work
for developers or compliance - Passed
Continuous improvement on logging and monitoring
IR and post-mortem process well established

42. References
• DevOpsSec: Securing software through continuous delivery
– https://www.safaribooksonline.com/library/view/devopssec/978149197
1413/
• DevOps Audit Defense Toolkit
– https://itrevolution.com/devops-audit-defense-toolkit/
• The DevOps Handbook: How to Create World-Class Agility, Reliability, and
Security in Technology Organizations
– Chapter 19
– Section VI
– Appendix 9
– https://www.amazon.ca/DevOps-Handbook-World-Class-Reliability-
Organizations/dp/1942788002

43. References
• Accelerate: The Science of Lean Software and DevOps: Building and
Scaling High Performing Technology Organizations
– Chapter 6
– https://www.amazon.ca/Accelerate-Software-Performing-Technology-
Organizations/dp/1942788339/
• Incident Management for Operations
– https://www.amazon.ca/Incident-Management-Operations-Rob-
Schnepp/dp/1491917628/
• Pagerduty Incident Response
– https://response.pagerduty.com/
• Incident Response: Trade-offs Under Pressure
– https://www.slideshare.net/InfoQ/incident-response-tradeoffs-under-
pressure

44. References
• Blameless PostMortems and a Just Culture
– https://codeascraft.com/2012/05/22/blameless-postmortems/
• The infinite hows
– https://www.oreilly.com/ideas/the-infinite-hows
• Debriefing Facilitation Guide
– https://extfiles.etsy.com/DebriefingFacilitationGuide.pdf
• Was it technical failure or human error?
– https://www.youtube.com/watch?v=Ygx2AI2RtkI
• AWS Monitoring & Logging
– https://www.slideshare.net/JasonPoley/aws-monitoring-logging
• Container & Microservice Security
– https://www.youtube.com/watch?v=8tDpGyVV8OQ
• How the Human Brain Buys Security
– https://www.schneier.com/essays/archives/2008/07/how_the_human_
brain.html