Download as PDF, PPTX
![[Security by risk assessment]
introduces a dangerous fallacy:
that structured inadequacy is
almost as good as adequacy and
that underfunded security
efforts plus risk management are
about as good as properly funded
security work
@wickett](https://image.slidesharecdn.com/locomocosec-v2-190417173117/75/The-Seven-Habits-of-the-Highly-Effective-DevSecOp-34-2048.jpg)
![[Deploys] can be treated as
standard or routine
changes that have been
pre-approved by
management, and that
don’t require a heavyweight
change review meeting.](https://image.slidesharecdn.com/locomocosec-v2-190417173117/75/The-Seven-Habits-of-the-Highly-Effective-DevSecOp-93-2048.jpg)
![[Chaos Engineering is] empirical rather
than formal. We don’t use models to
understand what the system should do.
We run experiments to learn what it does.
— Michael Nygard, Release It 2nd Ed.
@wickett](https://image.slidesharecdn.com/locomocosec-v2-190417173117/75/The-Seven-Habits-of-the-Highly-Effective-DevSecOp-148-2048.jpg)
Uploaded byJames Wickett
The Seven Habits of the Highly Effective DevSecOp
The document discusses the transformative concept of DevSecOps, which integrates security into the DevOps workflow to enhance efficiency and security in software development. It highlights the need for a cultural shift towards collaboration between development, security, and operations teams, emphasizing practices such as automation, experimentation, and unrestrained sharing of information. The author advocates for a proactive approach to security that aligns with agile methodologies and underscores the importance of understanding complex systems to mitigate security risks effectively.
More Related Content
Similar to The Seven Habits of the Highly Effective DevSecOp
The Seven Habits of the Highly Effective DevSecOp
- 1. THE SEVEN HABITSOF THE HIGHLY EFFECTIVE DevSecOp @WICKETT
- 2. JAMES WICKETT Sr. SecEng & Dev Advocate @ Verica Former Head of Research @ Signal Sciences Author, LinkedIn Learning Organizer, DevOps Days Austin, Serverless Days ATX, DevSecOps Days Austin Author, DevSecOps Handbook @wickett
- 4.
- 5. VERICA.IO An enterprise platformfor Continuous Verification, using Chaos Engineering principles, to take a proactive and measured approach to preventing availability and security incidents. @wickett
- 6.
- 7. credit to JoshZimmerman, the original DevOps Jack Handy
- 8.
- 9.
- 10. FIRST, UNDERSTAND DEVOPS AND HOWWE GOT HERE @wickett
- 12.
- 13. DATASo Big RightNow @wickett
- 14.
- 16. YASSS! OPS (andsecurity) FOR FREE!@wickett
- 17. DevOps grew hand-in-handwith cloud @wickett
- 18.
- 19. DevOps is theinevitable result of needing to do efficient operations in a distributed computing and cloud environment. Tom Limoncelli @wickett
- 20. DevOps is anepistemological breakthrough joining disparate people around a common problem @wickett
- 21. DevOps was neededto fix the inequitable distribution of labor @wickett
- 22.
- 23. DevOps is nota technological problem. DevOps is a business problem. - Damon Edwards @wickett
- 24. DevOps is justanother waypoint on Agile's journey across the business @wickett
- 25. DevOps is theapplication of Agile methodology to system administration — The Practice of Cloud System Administration Book @wickett
- 26. Ok DevOps, that'sfine. But why DevSecOps? @wickett
- 27. I ASKED MYSELFTHIS SAME QUESTION @wickett
- 28.
- 29. Security finds itselfin the same position that operations did in the movement of DevOps @wickett
- 30.
- 31.
- 32. Security, like opsstruggles to provide value in most organizations @wickett
- 33. Companies are spendinga great deal on security, but we read of massive computer-related attacks. Clearly something is wrong. The root of the problem is twofold: we’re protecting the wrong things, and we’re hurting productivity in the process. @wickett
- 34. [Security by riskassessment] introduces a dangerous fallacy: that structured inadequacy is almost as good as adequacy and that underfunded security efforts plus risk management are about as good as properly funded security work @wickett
- 35. While engineering teamsare busy deploying leading-edge technologies, security teams are still focused on fighting yesterday’s battles. SANS 2018 DevSecOps Survey @wickett
- 36. 95%OF SECURITY PROFESSIONALSSPEND THEIR TIME PROTECTING LEGACY APPLICATIONS @wickett
- 37. TECH BURDEN CANONLY BE TRANSFERRED @wickett
- 38. SECURITY BURDEN ISNOT CREATED OR DESTROYED, MERELY TRANSFERRED @wickett
- 39. "MANY SECURITY TEAMS WORKWITH A WORLDVIEW WHERE THEIR GOAL IS TO inhibit change AS MUCH AS POSSIBLE" @wickett
- 40. New technology (cloud,k8s, serverless, ...) and increased organization focus on software delivery is why we need DevSecOps. @wickett
- 41. A Highly DesireableNew Breed: THE DEVSECOP @wickett
- 42. ...not a tool …nota CI/CD pipeline with security in it ...can’t be bought on an expo floor @wickett
- 43. An inclusive personparticipating in the movement of security into devops. @wickett
- 44.
- 45.
- 46. MEASURE DEVSECOPS Maker Driven Experimenting Automating SafetyAware Unrestrained Sharing Ruggedizing Empathy First
- 47.
- 48.
- 49. We are softwareengineers who specialize in a specific discipline: security @wickett
- 50. SECURITY MUST BEABLE TO WRITE CODE@wickett
- 51. Why is thisconsidered a hot take in our industry? @wickett
- 52. With all theresources available today... @wickett
- 54.
- 55. SECURITY ALREADY USESDSLS @wickett
- 57. The Entire SecurityTeam Must Write Code Shannon Lietz, Intuit Aaron Rinehart, United Health Group @wickett
- 58. WHY IS THISIMPORTANT? ▸ Empathy building ▸ Familiarity with tools ▸ Able to move up the pipeline @wickett
- 59. A BUG ISA BUG IS A BUG @wickett
- 60. Defect Density studies rangefrom .5 to 10 defects per KLOC @wickett
- 61. DEFECT DENSITY IS NEVERZERO @wickett
- 62. But my applicationis just a few lines of code @wickett
- 63. 222 Lines ofCode 5 Direct Dependencies 54 total deps (including indirect) (example from snyk.io) @wickett
- 64.
- 67. You cannot traindevelopers to write secure code @wickett
- 68. INSTEAD, FOCUS ONMETHODS DEVELOPERS USE ▸ TDD/BDD/ATDD ▸ Meaningful comments/commits ▸ Code Smells, Refactoring ▸ Instrumentation @wickett
- 69. The goal shouldbe to come up with a set of automated tests that probe and check security configurations and runtime system behavior for security features that will execute every time the system is built and every time it is deployed.
- 70. Security is connected withquality @wickett
- 73. MAKER DRIVEN means ▸See security as part of engineering ▸ View quality as a way to bring security in ▸ Use code, not vendors to solve problems @wickett
- 74.
- 75.
- 76. BENEFITS TO EXPERIMENTATION ▸Measured, Repeatable ▸ Results based on your needs @wickett
- 77.
- 78. DETECT WHAT MATTERS ▸Account takeover attempts ▸ Areas of the site under attack ▸ Most likely vectors of attack ▸ Business logic flows ▸ Abuse and Misuse @wickett
- 79. We can't cedehome field advantage — Zane Lackey @wickett
- 80. EXPERIMENTING NECESSITATES UNDERSTANDING STEADYSTATE @wickett
- 81. RESOURCES ▸ Shannon Lietz(@devsecops) ▸ DOES 2018 Talk: youtu.be/ yuOuVC8xljw @wickett
- 82.
- 83.
- 85.
- 86.
- 87. AUTOMATION PROVIDES FEEDBACK ▸Pre-commit ▸ At build ▸ Deploy ▸ Runtime @wickett
- 88.
- 89. Continuous Delivery ishow little you can deploy at one time — Jez Humble & David Farley @wickett
- 90. At Signal Sciences,we optimized total cycle time--from code commit to running in prod @wickett
- 91. 15,000 DEPLOYS IN 3.5YEARS @wickett
- 92. SECURITY IN THEPIPELINE ▸ Software composition analysis ▸ Lang linters, git-hound, ... ▸ Scanners, gauntlt ▸ Monitoring and telemetry @wickett
- 93. [Deploys] can betreated as standard or routine changes that have been pre-approved by management, and that don’t require a heavyweight change review meeting.
- 94.
- 95.
- 96.
- 97.
- 98.
- 99. Two Stories ofFailure @wickett
- 100.
- 101.
- 102. 5 Why's andLinear Questioning is Flawed @wickett
- 103. WE ABSTRACT COMPLEXITY ▸Human beings ▸ Societial issues ▸ Psychological issues ▸ Cognitive load @wickett
- 104. SOFTWARE DEALS WITHCOMPLEXITY THROUGH ABSTRACTION @wickett
- 105. ROOT CAUSE ISA MYTH ▸ Lacks full picture ▸ Blame culture ▸ Forgets organizational decisions ▸ Puts the focus on the event over situation ▸ Complex systems are not linear @wickett
- 106. Drifting into failureis a gradual, incremental decline into disaster driven by environmental pressure, unruly technology and social proccesses that normalize growing risk. No organization is exempt from drifting into failure
- 107. BOEING 737MAX ▸ ManeuveringCharacteristics Augmentation System (MCAS) keeps the bigger plane from stalling ▸ The MCAS is automation software ▸ In certain situations, MCAS commands the trim in this condition without notifying the pilots @wickett
- 108. These events unfoldedin minutes, at low altitudes right after takeoff, asking pilots to realize, understand, and respond to why their aircraft was silently fighting their inputs
- 109. in a contextof being told that the “system” they were operating was pretty much like every other 737 they’d been likely to operate in their careers, ever. @jpaulreed
- 110. This new safetyautomation is capable of overriding operator input in silence and in ways that were poorly documented by designers, unclear to operators, and promised by developers
- 111. that nobody hadto get new training on — a selling point — and this safety automation proved to cause the system to become critically unrecoverable in, at least, one case. -- @jpaulreed
- 112. HIGH-SPEED DECISIONS ABOUT SYSTEMS,SOUND FAMILIAR? @wickett
- 113. SOFTWARE IS EATINGTHE WORLD @wickett
- 114. The growth ofcomplexity in society has got ahead of our understainding of how complex systems work and fail
- 115.
- 116.
- 117. Operations and Security's burdento rationalize system models @wickett
- 118. Failures are asystems problem because there is not enough safety margin. — @adrianco
- 119. Failure is aninevitable by- product of a complex system's normal functioning
- 120. WHERE SECURITY FITS ▸Add safety margin ▸ Telemetry and instrumentation ▸ Blameless retros ▸ ...more to explore in this area @wickett
- 121. RESOURCES ▸ Drift intoFailure by Dekker ▸ Understanding Human Error Video Series youtu.be/Fw3SwEXc3PU ▸ @jpaulreed coverage of Boeing medium.com/@jpaulreed ▸ Richard Cook paper bit.ly/2ydDQS2 @wickett
- 122.
- 123.
- 124. Culture is themost important aspect to devops succeeding in the enterprise — Patrick DeBois
- 125. DevSecOps is theextension of the DevOps culture for the inclusion of Security @wickett
- 126. A security teamwho embraces openness about what it does and why, spreads understanding. — Rich Smith
- 127.
- 128. Unrestrained Sharing goes againstsecurity's standard operating procedure @wickett
- 129.
- 130.
- 131. FOUR KEYS TOCULTURE ▸ Mutual Understanding ▸ Shared Language ▸ Shared Views ▸ Collaborative Tooling @wickett
- 132.
- 133. SECURITY SHARES THROUGH ▸Making invisible as visible ▸ Security Observability ▸ APIs, webhooks, dev tooling @wickett
- 134. Security Observability gives applicationsthe ability to expose the attacks that are happening below the surface with feedback to devs, ops, and security. @wickett
- 135. A PAVED ROADAPPROACH ▸ Security as normal ▸ Security is "free" @wickett
- 136.
- 138. RESOURCES ▸ Phoenix Project ▸Agile Application Security ▸ dearauditor.org @wickett
- 139.
- 140.
- 142. SOFTWARE BILL OFMATERIALS KNOW WHAT YOU HAVE @wickett
- 143. FAVOR SHORT LIVEDSYSTEMS CATTLE NOT PETS @wickett
- 144. DIE FRAMEWORK ▸ Distributed ▸Immutable ▸ Ephemeral ▸ source: @sounilyu @wickett
- 145. RUGGEDIZATION IN 2020 ▸Deception ▸ Chaos Engineering @wickett
- 146. DECEPTION ▸ Honeypots, Tarpits,Mantraps ▸ Simple to get started (http headers) ▸ HoneyPy, DeceptionLogic @wickett
- 147. We’re moving fromdisaster recovery to chaos engineering to resiliency — @adrianco @wickett
- 148. [Chaos Engineering is]empirical rather than formal. We don’t use models to understand what the system should do. We run experiments to learn what it does. — Michael Nygard, Release It 2nd Ed. @wickett
- 149. CHAOS ENGINEERING ▸ Experimentsthat span eng and security ▸ Manual opt-out ▸ Valuable Learning ▸ ChaosSlingr, CHAP, ChaosMonkey @wickett
- 150. RESOURCES ▸ Aaron Rinehart'stalk at RSA youtu.be/wLlME4Ve1go ▸ Release It! 2nd ed., Nygard ▸ Phillip Maddux's talk: youtu.be/k81xKjCEeqE ▸ Herb Todd's talk: youtu.be/Cf_XXmRLnRQ @wickett
- 151.
- 152.
- 154.
- 155. "you want amachine powered off and unplugged" — Developer @wickett
- 157. DON’T BE ABLOCKER BE AN ENABLER @wickett
- 158. MEASURE DEVSECOPS Maker Driven Experimenting Automating SafetyAware Unrestrained Sharing Ruggedizing Empathy First
- 159.
- 160.