Download as PDF, PPTX
![“[Chaos Engineering is]
empiricalratherthan formal.
We don’tuse modelsto
understandwhatthe system
should do.We run experiments
to learnwhat itdoes.”
Michael Nygard, Release It 2nd Ed.
@wickett](https://image.slidesharecdn.com/techstrong-v2-200604151914/85/A-Way-to-Think-about-DevSecOps-MEASURE-74-320.jpg)
![“[Deploys] can be
treatedas
standard or
routine changes
thathave been
pre-approved by
management,and
thatdon’trequire
a heavyweight
change review
meeting.”](https://image.slidesharecdn.com/techstrong-v2-200604151914/85/A-Way-to-Think-about-DevSecOps-MEASURE-84-320.jpg)
Uploaded byJames Wickett
A Way to Think about DevSecOps: MEASURE
The document discusses the concept of DevSecOps, emphasizing the integration of security practices within DevOps frameworks. It highlights the need for collaboration between security teams and developers, advocating for a maker-driven approach that includes experimentation and automation to address vulnerabilities in complex systems. Key themes include the criticism of traditional security practices, the importance of safety margins, and the necessity for a culture of mutual understanding and open communication in security practices.
More Related Content
Similar to A Way to Think about DevSecOps: MEASURE
A Way to Think about DevSecOps: MEASURE
- 1.
- 2. JamesWickett Head of Research@ Verica.io Author, DevOps on LinkedIn Learning Organizer, DevOps Days Austin, DevSecOps Days Austin @wickett
- 3.
- 4.
- 5.
- 6.
- 8.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. “The rumble ofthetwo trains,faintand far offat firstbut growing nearer and more distinctwith each fleeting second,was likethe gathering force ofa cyclone” @wickett
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. Aftermath: » 4 peopledied » Crush fired » Widespread injuries » Lawyers brought in for settlements @wickett
- 26.
- 27.
- 28.
- 29.
- 30. Learnings » Safety Marginexists in all Systems » Configuration errors and bullwhip effect » Experimentation can find vulnerabilities » Root cause is a myth @wickett
- 31.
- 32. DevOps isan epistemological breakthroughthatjoinsdisparate peoplearoundacommon problem ina distrubuted computearchitecture @wickett
- 33.
- 34. Securityfinds itselfinthe same positionthat operationsdid inthe movementofDevOps @wickett
- 35.
- 36.
- 37. “Companiesare spendingagreatdeal on security, butwe readofmassive computer-related attacks. Clearly something iswrong. The rootofthe problem istwofold:we’re protectingthewrong things,andwe’re hurting productivity inthe process.”
- 38. “While engineeringteams are busydeploying leading-edgetechnologies, securityteamsare still focused on fighting yesterday’s battles.” SANS 2018 DevSecOps Survey @wickett
- 39.
- 40. A Highly DesireableNew Breed: The DevSecOp @wickett
- 41.
- 42. The DevSecOpan inclusiveperson participating in the movementofsecurityinto devops. @wickett
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53. Securitysolves problems by writingcode @wickett
- 54. Whyisthis considered ahottake inour industry? @wickett
- 56.
- 57.
- 58. ASecurityTeamthatParticipates in Software Delivery »Empathy building » Familiarity with tools and teams » Able to shift left in the pipeline » Policy as Code approach @wickett
- 59.
- 60.
- 61.
- 62. Securityand Developer Collab »TDD/BDD/ATDD » Team Standards, reviews/config/comments/commits » Code Smells, Patterns, Refactoring » Instrumentation, Observability @wickett
- 63. “The goalshould beto comeupwithasetof automatedtests that probeand check security configurations and runtime system behavior for securityfeatures thatwillexecute everytimethe system is builtand every time itis deployed.”
- 66. Maker Driven means »See security as part of engineering » Use code, not vendors to solve problems » View quality as a way to bring security in @wickett
- 67.
- 68.
- 69.
- 70. “Securityincidents are not effective measuresofdetection becauseatthatpoint it'salreadytoo late” Aaron Rinehart @wickett
- 71.
- 72. “The securitydiscipline of experimentationis done in orderto build confidence inthe system’sabilityto defendagainstmalicious conditions.” @wickett
- 73. SecurityChaos Engineering (SCE) »Experiments that span eng and security » Manual opt-out » Valuable Learning » Controlled experiment blast radius @wickett
- 74. “[Chaos Engineering is] empiricalratherthanformal. We don’tuse modelsto understandwhatthe system should do.We run experiments to learnwhat itdoes.” Michael Nygard, Release It 2nd Ed. @wickett
- 75. SecurityProblems in ComplexSystems » Configuration drift over time » Regressions in code » Role and privilege drift » Additive code or microservices » Security controls in wrong locations » Bullwhip effect @wickett
- 76. SCE does not »validate a config, it exercises it » check auth privileges, it attempts to thwart them » trust network settings, it sends real traffic » check app policy, it interacts with the application @wickett
- 77. 4 Steps ofSecurityChaos Engineering »Define expected behavior of a security defense » Hypothesize that when security turbulence is introduced it will be either prevented, remediated, or detected. » Introduce a variable that introduces security turbulence. » Try to disprove the hypothesis by looking for a difference in expected behavior and actual behavior @wickett
- 78. Benefitsto Experimentation » Measured,Repeatable » Results based on your needs » Actionable Outcomes » A proven method to uncover truths in complex systems @wickett
- 79. Resources » principlesofchaos.org » ReleaseIt! 2nd ed., Nygard » DevOps Ent Summit Talk youtu.be/yuOuVC8xljw » Chaos Engineering, Rosenthal and Jones verica.io/ book @wickett
- 80.
- 81.
- 84. “[Deploys] can be treatedas standardor routine changes thathave been pre-approved by management,and thatdon’trequire a heavyweight change review meeting.”
- 85. “Continuous Deliveryis how littleyou can deployatonetime” JezHumble & David Farley @wickett
- 86. Securityinthe Pipeline » Softwarecomposition analysis » Lang linters, git-hound, ... » Scanners, gauntlt » Monitoring and telemetry @wickett
- 87.
- 88.
- 89.
- 90.
- 91. RootCause isaMyth inComplex Systems » Lacks full picture » Complex systems are not linear » Result of blame culture » Forgets organizational decisions » Puts the focus on the event over situation @wickett
- 92. Simple Systems: » Linearin nature » Easy to Predict » Able to comprehend @wickett
- 93. Complex Systems: » Non-linear(bullwhip effect) » Unpredictable in nature » No mental model available @wickett
- 94.
- 95.
- 96. “Failures are a systemsproblem because there is not enough safety margin. ” @adrianco @wickett
- 97. Where SecurityFits » Knowyour safety margin » Stop root cause analysis, go blameless retros » Telemetry and instrumentation » ...more to explore in this area @wickett
- 98. Resources » Drift intoFailure by Dekker » Understanding Human Error Video Series youtu.be/ Fw3SwEXc3PU » Richard Cook paper bit.ly/2ydDQS2 @wickett
- 99.
- 100.
- 101. “Asecurityteamwho embraces openness aboutwhatitdoes and why,spreads understanding.” Rich Smith @wickett
- 102.
- 103.
- 104. Four Keysto DevSecOpsCulture » Mutual Understanding » Shared Language » Shared Views » Collaborative Tooling @wickett
- 105. Resources » Phoenix Project »Agile Application Security » dearauditor.org @wickett
- 106.
- 107.
- 108.
- 109.
- 110. Favor ShortLived Systems CattlenotPets @wickett
- 111.
- 112. Rugged in 20211.AdvancedDeception 2. ContinuousVerification @wickett
- 113. Deception » Honeypots, Tarpits,Mantraps » Simple to get started (http headers) » HoneyPy, DeceptionLogic @wickett
- 114. Resources » Aaron Rinehart'stalk at RSA youtu.be/wLlME4Ve1go » Phillip Maddux's talk: youtu.be/k81xKjCEeqE » Herb Todd's talk: youtu.be/Cf_XXmRLnRQ @wickett
- 115.
- 116.
- 117. Developers don't have enoughtimeto spendon security
- 119.
- 120.
- 121. “Culture isthe most importantaspectto devopssucceeding inthe enterprise” Patrick DeBois @wickett
- 122.
- 123. Complimentary copy ofthe Chaos Engineering book verica.io/book @wickett
- 124.