Secure DevOps - Evolution or Revolution?
•Download as PPTX, PDF•
0 likes•340 views
DevOps continues to be a buzzword in the software development and operations world, but is it really a paradigm shift? It depends on what lens you view it through. Roman Garber, an active software security engineering and software team lead thinks so. Ed Adams, Security Innovation CEO, a 20-year software quality veteran and former mechanical engineer, curmudgeonly disagrees.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Secure DevOps - Evolution or Revolution?
Similar to Secure DevOps - Evolution or Revolution? (20)
More from Security Innovation
More from Security Innovation (20)
Recently uploaded
Recently uploaded (20)
Secure DevOps - Evolution or Revolution?
- 1. 1
- 2. 2 Secure DevOps: Revolution or Evolution Ed Adams eadams@securityinnovation.com @AppSec Roman Garber rgarber@securityinnovation.com
- 3. 3 About Security Innovation • For over 15 years, we’ve helped secure software in the toughest places: • Authors of 18 books on security topics (10 co-authored with Microsoft) • Over 2 million licensed users of our training solutions (12 awards this year) • Gartner Magic Quadrant leader
- 4. 4 Agenda • DevOps vs. other methodologies • Problems created/solved by DevOps • Best practices for resilient software
- 5. 5 DevOps vs. Other Methodologies
- 6. 6 Varying Views “Transform the way security controls are implemented and ensure they become business enablers” “Of Course it’s a fad. DevOps is the cool toy in the midst of Gartners (in)famous hype cycle. It delivers benefits but not on it’s promise” “DevOps is hereto stay” “Unstoppable deployment….. in small chunks of time”“Repeat Warning: There is No Silver Bullet in DevOps”
- 7. 7 DevOps vs. DevSecOps DevOps is a set of practices that automates the processes between software development and IT operations teams, so they can build, test, and release software faster and more reliably. Should (eventually) be the same thing
- 8. 8 The DevOps Promise(s) • Stop throwing software over the proverbial wall to IT, who’s expected to deploy and service it (headache free) • Make quality (including security) everyone’s responsibility • At every phase • Cross-skills/functional teams • Ops using developer techniques, e.g., source control • Dev considering IT metrics, e.g., performance • At regular intervals, team reflects on how to be more effective, then tunes and adjusts its behavior accordingly
- 9. 9 Security virtually non-existent Post deployment at best Manual Waterfall DevOps concepts introduced Widely adopted Align teams and tools Quality is everyone’s job Security extensions added later CMM/RUP/Agile Security-specific changes for CMM Last updated 2008 Captures best practices SSE-CMM Prescriptive Training for each role Security at Each Phase Prescriptive; “Too heavy-weight” Extensions added for Agile MS SDL Extension of DevOps Cross functional skills Align teams and tools Security is Everyone’s job Prescriptive but pliable “Game changer” DevSecOps Software Development – Last Few Decades
- 10. 10 Microsoft Patterns & Practices: Security Engineering Cheat sheet (2007) These techniques and approach shipped with VSTS/MSF Agile starting in 2005
- 11. 11 Q: Revolutionary or Evolutionary? Evolutionary • Same concepts existing 20 years ago • We keep updating/refining the same practices o Just new words and modernized tools Revolutionary • While DevOps builds on agile and iterative development, integrating tightly and releasing multiple times/day is disruptive • Manager vs. Practitioner view: o How am I going to review all these releases? o Automation helps, but I still have to know a lot o Very different than “ok lets review what you got model prior”
- 12. 12 Where are you in terms of Secure DevOps rollout? • Gathering data • Starting to Implement • In optimization mode
- 13. 13 Problems Solved/Created by DevOps
- 14. 14 The Business Case for DevOps
- 15. 15 Misalignment is Real • 64% of C-suite respondents believe security teams are involved in technology design and deployment • 39% at the practitioner/team level believe so • Highly-evolved organizations • 24 times more likely to always automate security policy configurations compared to the least evolved organizations • As organizations evolve, security policy becomes part of operations • Not just an afterthought when an audit looms • This requires first breaking down boundaries between Dev, Ops, and Security teams Source: 2018 State of DevOps Report from Puppet
- 16. 16
- 17. Where’s the Disconnect…? Source: “2018 Application Security Report,” Cybersecurity Insiders
- 18. 18 Q: Is primary value improving overall security, or getting software released sooner with minimal risk? Better quality • In time this means faster release cycles • Few defects/re-work; more time on features Getting Feature out the Door sooner • You don’t know something works until you try it • Can’t plan for everything because life is what happens while you are busy planning • Business needs to market test features fast, measure success and pivot
- 19. 19 Problems DevOps Can Create • Temptation to over-automate • Too much reliance on tools • Info/data overload (why SIEMs were created in the first place) • DIY tools • Cheaper/better to write myself • Build a ballfield, someone has to mow the lawn • How to properly integrate with existing processes and infrastructure • Security knowledge dilution • Promotes wider, general knowledge rather than specialized focus • Quality is everyone’s job • …so, it’s always someone else’s job!
- 20. 20 Best Practices for Resilient Software
- 21. 21 Q: Is it more about the tools, mindset or methodologies? Tools, Tools, Tools • The methodologies are all the same • The mindset is what is was in 1998 (20 years ago) • What’s different is the technology and tools to implement the mindset and culture change Mindset & Culture Change • Large corporations have departments of development, business, security security • Don’t work well together, throw over the fence • Everyone needs to work together as one team, no my job-your job mentality
- 22. 22 Continuous & Iterative Assessment • Design Analysis • Mapping security requirements to code identifies potential automation points • Securing the Design • For security and component reuse, identify insecure APIs, and frameworks • Secure them to enable recycling and minimize new development • Software Security Code Review • Review in small chunks, analyzing only newly, re-written or high risk code • Focus on “hot spots” in code, frameworks and components • Software Security Assessment • Leverage scanners for breadth and specialized tools for depth • Secure Operations • Look for secure by default deployment stacks • Ensure resilience against persistent external attacks at all layers
- 23. 23 Threat Mitigation Vulnerability Attacker DevOps Security Glue: Threat Modeling Vulnerabilities are unmitigated threats Here’s our opportunity! • Secure applications start with understanding the threats • Threats are not vulnerabilities; they live forever and are attack vectors • If done at each phase, provides more leverage than any other security activity
- 24. 24 Q: If you are _____, then you have not implemented or realized the benefits Secure DevOps MOST Organizations • Just like ”moving to the cloud” everyone is talking about it, but few are actually DOING it • Secure DevOps is nothing more that resilient, quality-conscious software development NO Finite moment • CI/CD means continuous improvement and deployment • Release fast, release often measure value, keep or throw • Maintain risks at acceptable level, don’t expose clients data
- 25. 25 Build Security Champions • Security team can help, but not sufficiently when dealing with multiple teams and lack of security culture • Champions are practitioners that serve as mentors, help determine when to engage the security team and serve as a single point of contact • Clearly define their goal and responsibilities, which often include: • Conduct and/or verify security reviews in the team • Guard and promote best practices. • Raise issues for risks in existing and new code • Build threat models for new features • Investigate bug bounty reports • Participate in R&D activities • They should be the most knowledgeable and passionate about software security, and understand how engineering activities feed off each other
- 26. 26 The Microsoft SDL: Reduction in Vulnerabilities 119 66 400 242 157 Windows® XP Windows Vista® OS I OS II OS III Total Vulnerabilities Disclosed 12 Months After Release 34 3 187 SQL Server® 2000 SQL Server 2005 Competing commercial DB Total Vulnerabilities Disclosed 36 Months After Release Before SDL After SDL 45% reduction in Vulnerabilities Before SDL After SDL 91% reduction in Vulnerabilities Consistent use of sound security practices, regardless of which ones, during all phases of development will reduce risk and facilitate compliance
- 27. 27 Q: DevOpsSec, SecDevOps, DevSecOps? Who Cares What You Call It? • Just do it right • Same premise: get aligned, share nomenclature & tooling, etc. • Remove the “Sec” and just think quality The Same, But Different • You can knit-pick with no value • Ultimately doesn’t matter as long as risks are under control
- 28. 28 Summary • Software security is not just a developer problem • Each phase of development is an opportunity to introduce or mitigate risk • Secure DevOps can solve some plaguing issues: • Lack of cross-functional knowledge between build and deployed state • Security slowing down ability to get features out the door • Success of DevOps (or any other methodology) relies on 3 key principles • Automate what can be done faster than humans • Conduct manual inspections to find problems that elude tools; especially with high risk features/applications • Balance tools, knowledge, and process – each feeds into one another
- 29. 29 Polling Question • What do you think? Is DevOps Evolution or Revolution?
- 30. 30 Maintaining DevOps Security Skills • Experts predict a shortage of 3.5 million cybersecurity professionals for 2021* • It’s hard to build a strong DevOps outfit without expertise to support it • Organizations need to innovate their approach to grooming security personnel • If everyone needs to be responsible for security, then everyone needs to understand how applications are attacked *https://www.csoonline.com/article/3200024/security/cybersecurity-labor-crunch-to-hit-35-million-unfilled-jobs-by-2021.html
- 31. 31 CMD+CTRL: Application Security Cyber Range Remote Access Detailed Reports Remediation eLearning available Seven Authentic App Sites Real time scoring Scalable to hundreds in minutes CMD+CTRL
- 32. 32 • Start by finding vulnerabilities • Really powerful, eye-opening activity • Most exciting part of security (the “hack”) • You can’t create resilient code until you know how it fails • Augment existing test cases with proven new ones • Learn how design and IT configurations can be circumvented • Understanding failures helps humans prevent them: • This is why we have practices and pre-season games in sports • Assess real-world preparedness so you can take the right action • Drives home the need for standards, policies, and requirements • Provides value added feedback to co-workers Cyber Range: The “A-ha” Moment
- 33. 33 Application Security Computer-Based Training • 150+ courses for software development and deployment • 40 Learning paths by role, platform, technology DevOps Learning Path • Fundamentals of Secure Development • Fundamentals of Secure Architecture • Securing Network Access • Securing Operating System Access • Securing Cloud Instances • Application & Technical Access Controls • Essential Security Engineering Principle • Essential Application Protection • Essential Data Protection • Fundamentals of Threat Modeling • Fundamentals of Security Testing
- 34. 34 Hacking the Holidays • From December 21st – January 4th, we are giving limited-time free access to our CMD+CTRL Cyber Range. • If you are interested in participating, please email us at getsecure@securityinnovation.com and we will send you an invitation.
- 35. 35 Questions?
Editor's Notes
- I’m very excited to be on stage for the first time. This is my 7th DEF CON and I’m proud to be able to give back to the community today.
- We’ve discussed how the system works from an end-users perspective. Now let’s get technical. Discussing the “specification” level. “Specification” “Implementation” “Deployment”
- Design analysis Mapping security requirements to code identifies potential automation points Understanding how testing points can drive configuration changes lets you use existing tools/technology wisely. Securing the Design To properly plan for security and component reuse, it’s important to identify insecure APIs and frameworks Securing these components enables recycling and minimized new development Review design to ensure security-sensitive elements (e.g. password requirements, user authentication mechanisms) and secure deployment options are defined so they can be coded properly. Software Security Code Review DevOp calls for rapid code reviews in small chunks, analyzing only newly or re-written code While this makes it easy for developers to push modular code to production, certain features need to undergo deeper inspection before deployment To facilitate continuous review as part of DevOps cycles, we focus on “hot spots” in code bases, frameworks and components, offering both rapid and deeper-level code analysis. Software Security Assessment Leveraging scanners for breadth and specialized tools for depth Harden Deployment Look for secure by default deployment stacks, have they hardened their images? Do they have a patch management system in place for their servers? Hackers constantly scan, test, and attack all layers of your organization; Ensure your resilience against persistent external attack to identify vulnerabilities that can lead to a breach or be used to traverse to other more valuable assets. If their servers are full of vulnerabilities, then their deployed software will also be compromised. IT and software security go hand in hand, and one can't compensate for the other,
- Thinking about this and talking it through with team members here at Security Innovation gave me flashbacks to the 1990’s when I was working at Rational Software and talking with my boss Sam. I quite literally had the exact same conversation with him when discussing how our products would solve the exact same problems… in precisely the same way! We even wrote books and created a “new” software development process that embodied these characteristics. It was called Rational Unified Process (RUP), an iterative software development framework that heavily leverages automation, shares work items across all teams, and streamlines communication from inception through deployment. Agile, eXtreme Programming, continuous integration, The Microsoft SDL, and a number of other process methodologies were also built on the same premise – faster sprints versus marathons, using automation wherever you can, aligning team members and sharing assets, blah, blah, blah.
- This diagram does a good job of showing how the security engineering activities can be layered into a normal software development process. Whether you use waterfall or agile, you probably already perform many of the core activities shown in this diagram. To add security engineering you simply add security activities at the appropriate times. For instance when you would normally determine your functional requirements you would also determine your security objectives. When you would normally apply design best practices you now apply security design best practices as well. Security engineering does not require that you change your existing process, just augment it with a set of high-impact security activities.
- ROMAN I like this one because it ties both DevOps and DevSecOps. This is about the direciton on how I would answer this - While DevOps is building on agile practices and concepts of iterative development, integrating this into the whole operation and releasing 2-10 times per day is a revolutionary concept that was hard to get your head around for a security professional. The number one question in my mind was - How am I going to review all these releases?! Sure automation helps, but it only catches so much. This is DevSecOps comes in. Not just automate, but integrate into every part of the cycle where security minded developers make security decisions because they have skills and knowledge, and where security practitioners are called upon by these engineers as necessary when needed. This is very different from - ok lets review what you got model prior.
- We’ve discussed how the system works from an end-users perspective. Now let’s get technical. Discussing the “specification” level. “Specification” “Implementation” “Deployment”
- The best way to get everyone on the same page is through the mutually reinforcing DevOps pillars of automation and measurement. Automated systems enable better reporting of metrics that can be shared across the business. (which are further from production). As we see with all the fundamental practices of DevOps, this practice evolves from resolving immediate pain to a more strategic focus — in this case, from “keep the auditors off my back” to “keep the business and our customers’ data secure.” In other words, teams automate security policy configurations initially for their own benefit, and as their understanding evolves, the automation evolves to benefit the entire organization.
- Only 39% conduct regular security code reviews (MS SDL called it as a best practice 10+ years ago)
- ROMAN I like this too. Maybe we should start with this as it introduces the need for devops. My direction would be that development is hard, customer comms is hard, biggest disappointment is expectations, so release early - release often. This is not new, startups did this back in the 90s. What is new and revolutionary is scaling this to a large enterprise where someone like Target or Ryanair, or Reuters can make couple of releases per day, see what works, what doesn't and focus on adjusting to business environments as if they were a 6 person startup. (I could go into my own experience of working at a 6 person startup in the 90s)
- We’ve discussed how the system works from an end-users perspective. Now let’s get technical. Discussing the “specification” level. “Specification” “Implementation” “Deployment”
- ROMAN RG>> I would go that this is the mindset and culture change. Traditionally bigcorp have a culture of silos where dev, security, ops, business are different silos that each do "their thing". DevOps breaks down the silos and makes the company as a whole more agile. This does require training. The no developer can say that "I only do Cobol". Ops need to script things, need to know what they are deploying and how it interacts with other components. Devs need to know more about the environment and deployment but importantly they need to know how whatever they code be secured and what they need to know about security in order to write secure code. The ownership is now on them not on the security dept.
- Secure by default deployment stacks: have they hardened their images? Do they have a patch management system in place?
- Requirements - Need single-sign-on or MFA? What’s the security benefit/risk? Design – helps architects choose secure components/technologies and ensure design meets the level of acceptable risks Testing – determine if the application holds up against the types of attacks envisioned during the threat modeling exercise Acceptance testing - Identify risks associated with outsourced development and supercharge SLAs with acceptance criteria Deployment - Conduct a deployment review against threat model to ensure server configurations are appropriate Operations – assess potential security risks and make informed decisions before change management events
- ROMAN "Features are built based on anticipated value to the business but if they don’t deliver – its fail fast, learn the lessons and move forward. Equally if the feature works well then Labs roll out by culture (Ryanair groups by language not country). Of course not all cultures behave the same way; for example Italians tend not to buy car insurance at the same rate as English people.’" So basically if you are not building features fast, measuring their value and ether keep or throw, you are not doing DevOps. If you are exposing yourself, consumers, clients etc to additional and unacceptable risk as you do so, you are not doing DevSecOps
- 12 months after the Microsoft SDL was rolled out internally to all Microsoft Development Teams, there was a 45% reduction in vulnerabilities in Windows 36 Months after the SDL was rolled out, there was a 91% reduction in SQL server
- ROMAN These are all "same same but different" and you can treat this ether as just a different nomenclature or get picky and say that the name implies where one applies security. In the latter case I'd argue that SecDevOps is the way to go, since you start with security minded requirements. But I am not sure if this is too knit-picky for this webinar.
- Security/Program Managers Drives home the need for standards, policies and requirements Measures competency over time and drives training plans Architects Understand common development mistakes and translate that into better design constraints Understand how design mitigations can be circumvented Developers Realize how your coding mistakes facilitate attacks Adopt a defensive code vs. functional code mentality Testers/QA Augment your test cases with new security attacks Provide value added vulnerability insight back to developers IT/Operations Understand how deployment options assist a secure software development process See how mitigating/compensating controls can be circumvented