Security and DevOps

Talks about DevOps and how security teams can be part of it.

Transcript

1. Implementing Security with DevOps Matt Konda Jemurai
2. Agenda • Introductions • What is DevOps to Security • Case Study 1 • Case Study 2 • Pipeline • Conceptual framework • Maturity Model • OWASP Projects • How to Get Involved
3. Introduction 1997 2006 2014 Consultant Engineer Software Architect Director of Engineering Rabble Rouser: Perl Java Applet C++ J2EE J2EE
 Spring Analytics Certificate Authority Vulnerability Scanner Penetration Test Manager Pricing Retail Banking Manufacturing Pharma Healthcare Research Ruby Rails Chicago BSides 2011, 2012 Defcon Skytalk OWASP Chicago, MSP 2013 AppSec USA 2012, 2013 ChicagoRuby 2013 Secure 360 Lone Star Ruby 2013 WindyCityRails 2013 Chicago JUG 2014 RailsConf 2014 Converge 2014 MS in CS Founder Consultant Agile Clojure Graph Database Trying to hack a business model that succeeds while helping developers. Domains: Projects: DevOps / Automation Training Coaching Code Review Plugged in to SDLC Consulting Assessments @mkonda mkonda@jemurai.com DevOps Growing
4. Census?
6. What is DevOps?
7. In my opinion, DevOps is basically Agile extended to include Ops as first class stakeholders.
8. Of course, it is also a result of an increasingly cloud oriented Ops environment that is scripted with Chef, Puppet, Ansible, etc.
9. automation
11. visibility
12. mttr Mean time to repair
13. mttd Mean time to detect
14. empathy
15. accountability
16. culture
18. OK OK … but what does this actually mean for security?!?!?
20. We’re trying to get on the bandwagon.
21. SecDevOps DevSecOps DevOpsSec Rugged DevOps
22. Reinforces something I learned as a developer: naming is hard.
23. I think that security should just be implied by DevOps and doesn’t need to have another name.
24. Why do we care?
25. Being able to deploy quickly is my #1 security feature. - Nick Galbreath
26. Personally: I have never seen anything change development/IT like this.
27. Case Study #1
28. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
29. Need somewhere to keep an inventory of applications.
30. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
31. Always a way for human intervention.
32. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
33. Automation
34. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
35. Digest and filter
36. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
37. Communicate with developers
38. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
39. Visibility
40. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
41. Scripted provisioning
42. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
43. Credit: Matt Tesauro at AppSecEU 2015 http://www.slideshare.net/mtesauro/mtesauro-keynote-appseceu
44. Case Study #2
45. App Inventory Pipeline CSV, JSON, Text Git webhooks Jenkins
46. Need somewhere to keep an inventory of applications.
47. App Inventory Pipeline CSV, JSON, Text Git webhooks Jenkins
49. Devs can interact and trigger security checks.
51. Automation
52. App Inventory Pipeline CSV, JSON, Text Git webhooks Jenkins
53. Digest and filter
54. App Inventory Pipeline CSV, JSON, Text Git webhooks Jenkins
55. Communicate with developers
56. App Inventory Pipeline CSV, JSON, Text Git webhooks Jenkins
57. Visibility
59. App Inventory Pipeline CSV, JSON, Text Git webhooks Jenkins
60. Scripted provisioning
61. App Inventory Pipeline CSV, JSON, Text Git webhooks Jenkins
62. Most parts of this automation toolchain are open source and offer multiple ways to interact…
63. Pipeline
65. Intended to make it easy to do security automation.
67. Mounter Currently: git repo, filesystem, iso, docker image
68. Mounter Currently: clamav, hashdeep Files
69. Mounter Currently: brakeman, bundler-audit, owasp-dependency-check, secrets in source, retire.js, scan.js Future: many more possible. Designed for extension. Files Code
70. Mounter Currently: ZAP (in progress) Future: guantlt, etc. Files Code App
71. Mounter Currently: Prevents false positives in JIRA. Files Code App Filter
72. Mounter Currently: Reports to JIRA, csv, json, text. Files Code App Filter Reporter
74. Extension Points • Mounters: mount, supports? • Tasks: run, analyze, supported? • Filters: filter • Reporter: run_report Mounter Files Code App Filter Reporter “Tasks”
75. Other Internals • Within “Tasks”, each of the files, code and app phases of the pipeline can be run selectively. Mounter Files Code App Filter Reporter “Tasks”
76. ruby bin/pipeline -l code (Code analysis) -d (Turn on debug) -f text (Output format) /area53/app/
77. Some valid…
78. Still noisy … but you can dismiss and move on and hopefully rarely see them.
79. What if it just automatically ran against every company github project?
80. Conceptual Framework for Security in DevOps
81. Two passes • First talk about security overlaid on continuous delivery model • Then talk about event based security and DevOps related activities
82. Understand lifecycle
84. continuous delivery
85. Security sees this and wants to …
86. continuous delivery
87. But we should embrace it.
88. Think incremental
90. continuous delivery Code Review Security Unit Tests Security Requirements
91. Automate security tools
92. continuous delivery Security Tool Automation: Code analysis Security unit tests Dynamic scanning etc.
93. continuous delivery Security Tests Run Exploratory Testing Includes Security
94. A detailed example: • Let’s say a feature is being developed • Then devs and testers are checking a new feature • Let them browse through an attack proxy (like Burp or ZAP) in passive mode • At night or when the system is quiet, use the browsing pattern as seeds for overnight attacks
95. Continuous feedback
96. continuous delivery Feedback!
97. EVIL False Positives Are a Necessary
98. Optimize for relevance
99. Provisioning tools
100. continuous delivery Since its easy to provision we can do security testing safely in a new env.
101. Audit tools
102. continuous delivery Deployment checks includes security audit checks.
103. Self documenting for regulatory and compliance!
104. Collect important data
106. Chaos tools
107. Change is good
108. continuous delivery Change is happening. It can be an opportunity instead of a hassle.
109. Complexity is an enemy
110. continuous delivery Small releases reduce complexity. Decomposition to micro-services reduces dependencies and complexity. Right now, security hurts.
111. Shared responsibility
112. continuous delivery Another principle of software delivery: build security in! Done means secure! Empowered to do security right!
113. Measure results
114. Event based model … (Reactive)
115. Commit • Security Unit Tests • Static Code Analysis (Pipeline) • Security Requirements • Check Dependencies • Code Review • Checklists
116. Deploy • Scripted Provisioning / Built in Change Control • Provisioning Auditing (Chef Audit, hardening.io) • Gauntlt
117. Periodic • Full app analysis (static, manual pen test) • Secure Development Training • Baseline Security Requirements Review • ASVS Review • Data Science on Results
118. Security Incident
119. Maturity Model
120. How do we know what to actually DO?
121. Belts
122. Defining Kata
123. Kata Name: Run ZAP Proxy Daily Kata Detail: Automate a way to run ZAP Proxy against an app on a daily basis and report issues to Jira How to Do the Kata: Activate “XYZ” Jenkins Plugin Training Resource: A web page with specifics about this Kata. Experts: A reference to people that can help with this Kata. Difficulty: Belt level for the Kata. Security Objectives: What security objectives does this Kata help us to achieve?
124. Data Classification OWASP Top 10 Training Simple Developer Environment Setup Continuous Integration and Testing Source Code Repository and Proper Tags Repeatable Deployment HTTPS (TLS) Everywhere
125. Baseline Security Requirements Test for Security Headers Lockout to Prevent Brute Force Consistent Output Encoding Audit Records Written IDE Style Checks Villain Persona and Security Requirements Operational Metrics Unauthenticated Scanning
126. Storing Secrets Solid SSL Security of Dependencies Audit Records Written Anti DoS Anti-CSRF Protection Consistent SQL Injection Protection Static Analysis Vulnerability Scanning Authenticated Application Scanning Security Code Review
127. Logs Aggregated with Security Event Incident Management System Appropriate Encryption Antivirus / Malware Business Metrics HSTS and Certificate Pinning Application Penetration Testing
128. Attack Awareness Behavioral Blocking Centralized Security Service Security Unit Tests for Business Logic Hands on Developer Security Training Dynamic Analysis Runtime Application Security Analysis Application Honeypot
129. Up, Up, Down, Down, Left, Right, Left, Right, B, A, Start.
130. The intent is not to force everyone to do every one of those things. The intent is to help to identify the things that can be done and layer them so that they can be prioritized.
131. This is actively evolving. You can help!
132. OWASP DevOps Related Projects
133. AppSec Pipeline Documentation Project https://www.owasp.org/index.php/ OWASP_AppSec_Pipeline
134. To include: Case studies Best practices Data sharing
135. Josh Corman Matt Tesauro Aaron Weaver Shannon Lietz James Wicket Mercedes Cox Aaron Tesch Matt Konda You … ?
136. Pipeline Tools Project https://www.owasp.org/index.php/OWASP_Pipeline_Tool_Project github.com/owasp/pipeline
137. Developer focused security pages: owasp.github.com/dev-pages
138. Thank you.
139. I recognize that software has become a foundation of our modern world. I recognize the awesome responsibility that comes with this foundational role. I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended. I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security. I recognize these things – and I choose to be rugged.
140. I recognize that software has become a foundation of our modern world. I recognize the awesome responsibility that comes with this foundational role. I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended. I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security. I recognize these things – and I choose to be rugged.
141. References • https://speakerdeck.com/garethr/maintaining-control-by-letting-go-security-and-devops • http://www.slideshare.net/nickgsuperstar/devopssec-apply-devops-principles-to-security • https://www.rsaconference.com/writable/presentations/file_upload/asd-t07r-continuous- security-5-ways-devops-improves-security.pdf • https://github.com/owasp/pipeline • http://gotocon.com/goto-london-2015/ • https://www.owasp.org/index.php/OWASP_AppSec_Pipeline • http://gauntlt.org/ • https://github.com/PearsonEducation/bag-of-holding • https://www.ruggedsoftware.org/
142. Thank you.