Security in the age of open source - Myths and misperceptions
•Download as PPTX, PDF•
1 like•289 views
As delivered at Interop ITX 2017. The security of open source software is a function of the security of its components. For most applications, open source technologies are at their core, but security related issues may not be disclosed directly against the application because its use of the open-source component is hidden. In this talk, I explored how information flow benefits attackers, but how awareness can help defenders. I presented key attributes any vulnerability solution should have - including deep understanding of how open source development works and being DevOps aware.
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Similar to Security in the age of open source - Myths and misperceptions
Similar to Security in the age of open source - Myths and misperceptions (20)
More from Tim Mackey
More from Tim Mackey (18)
Recently uploaded
Recently uploaded (20)
Security in the age of open source - Myths and misperceptions
- 1. Security in the Age of Open Source - Myths and Misperceptions Interop ITX 2017
- 2. #whoami – Tim Mackey Current roles: Senior Technical Evangelist; Occasional coder • Former XenServer Community Manager in Citrix Open Source Business Office Cool things I’ve done • Designed laser communication systems • Early designer of retail self-checkout machines • Embedded special relativity algorithms into industrial control system Find me • Twitter: @TimInTech ( https://twitter.com/TimInTech ) • SlideShare: slideshare.net/TimMackey • LinkedIn: www.linkedin.com/in/mackeytim
- 3. I don’t use much open source, so security isn’t an issue I know all of the open source I use and have it covered The NVD gives me everything I need to find and fix open source vulnerabilities quickly 3 BIG MYTHS 1 2 3
- 4. Understanding the Attacker Model Its all about information flow
- 5. Vulnerability Management Implies Data Breach Management 89% of data breaches had a financial or espionage motive Legal costs and forensics dominate remediation expenses Source: Verizon 2016 Data Breach Report
- 6. Attackers Decide What’s Valuable …
- 7. Anatomy of a New Attack Potential Attack Iterate Test against platforms Document Don’t forget PR department! Deploy
- 9. CLOSED SOURCE COMMERCIAL CODE • DEDICATED SECURITY RESEARCHERS • ALERTING AND NOTIFICATION INFRASTRUCTURE • REGULAR PATCH UPDATES • DEDICATED SUPPORT TEAM WITH SLA OPEN SOURCE CODE • “COMMUNITY”-BASED CODE ANALYSIS • MONITOR NEWSFEEDS YOURSELF • NO STANDARD PATCHING MECHANISM • ULTIMATELY, YOU ARE RESPONSIBLE Who is Responsible for Code and Security?
- 11. Bug Report Submitted glibc Bug Reported July 2015 Vuln: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow
- 12. glibc 2.9 Vuln Introduced May 2008 glibc Bug Reported July 2015 CVE-2015- 7547 CVE Assigned Feb 16-2016 Low Security Risk Vuln: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow Assessment Complete – CVE Assigned
- 13. glibc 2.9 Vuln Introduced May 2008 CVE-2015- 7547 CVE Assigned Feb 16-2016 glibc Bug Reported July 2015 National Vulnerability Database Vuln Published Feb 18-2016 Moderate Security Risk Low Security Risk Vuln: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow Vulnerability Publication
- 14. glibc 2.9 Vuln Introduced National Vulnerability Database Vuln Published You Find It May 2008 CVE-2015- 7547 CVE Assigned Feb 16-2016 Feb 18-2016 glibc Bug Reported July 2015 Patches Available You Fix It Highest Security Risk Moderate Security Risk Low Security Risk Vuln: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow Resolution
- 15. Awareness Timeline How even embargoed vulnerabilities stay hidden
- 16. Media Coverage Embargo Expires Oct 21 2016 Git://id Upstream Patch Vuln: CVE-2016-5195 – AKA “Dirty Cow” Embargoed Vulnerability Awareness Oct 18 2016 Patches Available
- 17. Patches Available Media Coverage Embargo Expires Oct 21 2016 Git://id Upstream Patch Vuln: CVE-2016-5195 – AKA “Dirty Cow” Timing is Opportunity Oct 18 2016 National Vulnerability Database Vuln Published Nov 10 2016 Highest Security Risk
- 18. Understand what is deployed Avoiding regrettable decisions
- 19. Attackers Find Weaknesses – Don’t Give Them Opportunities OpenSSH: AllowTCPForwarding creates open IoT proxyApache Struts: Vulnerability response time mattersHeartbleed: Why in 2017?
- 20. Implications of an Agile World
- 21. Start with Sprint 0 Requirements and Backlog Verification Sprint 0 Strategy & Metrics Compliance & Policy Standards and Requirements Security Features & Design Software Environment
- 22. Retrofitting SDL Concepts into Modern Methodologies Verification Strategy & Metrics Compliance & Policy Learnings Standards and Requirements Security Features & Design Design Review of Stories Software Environment Sprint 0 Attack Models Code Review Security Testing Vulnerability Management Penetration Testing
- 23. Identifying Manual Security Activities Verification Strategy & Metrics Compliance & Policy Attack Models Standards and Requirements Security Features & Design Code Review Security Testing Vulnerability Management Software Environment Sprint 0 A M Automated Manual Penetration Testing Learnings Design Review of Stories
- 24. Automating Activities to Reduce Effort Verification Strategy & Metrics Compliance & Policy Attack Models Standards and Requirements Security Features & Design Code Review Security Testing Vulnerability Management Software Environment Sprint 0 A M Automated Manual Penetration Testing Learnings Design Review of Stories
- 25. Increasing Automation to Match Development Speed Verification Strategy & Metrics Compliance & Policy Attack Models Standards and Requirements Security Features & Design Code Review Security Testing Vulnerability Management Software Environment Sprint 0 A M Automated Manual Penetration Testing Learnings Design Review of Stories
- 26. Reducing Dependency Risks Verification Strategy & Metrics Compliance & Policy Attack Models Standards and Requirements Security Features & Design Code Review Security Testing Vulnerability Management Software Environment Sprint 0 A M Automated Manual Penetration Testing Design Review of Stories Learnings
- 27. Open Source Risk Maturity Model
- 28. LEVEL 1 – BLISSFUL IGNORANCE No policies in place to manage open source security and licensing risks. Unknown versions and dependencies. No documentation of intent.
- 29. LEVEL 2 – AWAKENING Inconsistent manual processes to identify and report on open source usage. Conceptual awareness of license requirements. Unaware of security implications of open source usage.
- 30. Vulnerability Analysis Compliments SAST/DAST All possible security vulnerabilities Static and Dynamic Analysis - Discover common security patterns - Challenged by nuanced bugs - Focuses on your code; not upstream Vulnerability Analysis - Identifies vulnerable dependencies - 3000+ disclosures in 2015 - 4000+ disclosures in 2016 - Most vulnerabilities found by researchers
- 31. LEVEL 3 – UNDERSTANDING Manual review processes, and basic tooling. Primary focus on license compliance. Accuracy is difficult to maintain. Provides limited insight into security vulnerabilities. Tools: Spreadsheets, low cost tools, sporadic security scans
- 32. But security investment is often not aligned with actual risks
- 33. LEVEL 4 – ENLIGHTENMENT Automatic identification of open source components and versions. Direct mapping to licenses and disclosed vulnerabilities. Integration with developer, issue management, CI/CD and deployment tools.
- 35. 8,800 DATA SOURCES 530 TERABYTES OF CONTENT 2,400 LICENSE TYPES 12 YEARS OF OSS ACTIVITY 84,000 OSS VULNERABILITIES • Designed with Open Source behavior traits including forks and merges • Vulnerability information enhanced through dedicated security research team • Real time updates as security issues occur • Maps vulnerabilities to public exploits Comprehensive KnowledgeBase
- 36. Define Actionable Risk Elements Open source license compliance • Ensure project dependencies are understood Use of vulnerable open source components • Is component a fork or dependency? • How is component linked? Operational risk • Can you differentiate between “stable” and “dead”? • Is there a significant change set in your future? • API versioning • Security response process for project
- 37. Solving for Open Source Disclosures Distributed Weakness Filing • Open Source specific CAN • Designed for Open Source projects without an existing CAN Increasing vulnerability awareness • Reinforce security collaboration • Reduce islands of knowledge https://iwantacve.org https://github.com/distributedweaknessfiling/
- 38. Question the “Newer Version” Patch Process
- 39. Support Gating of Builds for Risk Elements DEVELOP BUILD PACKAGE RISK ASSESSMENT BUG TRACKING
- 40. Support Ongoing Monitoring for Changes in Risk DEVELOP BUILD PACKAGE DEPLOY PRODUCTION BUG TRACKING TEST AUTOMATION RISK ASSESSMENT
- 41. Container Orchestration Increases Velocity Red Hat OpenShift as reference case
- 42. Integration Points for OpenShift Container Platform
- 43. Black Duck OpenShift Integration Component Identification Black Duck KnowledgeBase Customer Hosted Black Duck Hosted Integrated Registry ImageStream Events Policy Engine Hub Scan Engine Hub Scan Controller Hub Notifications Image Annotation External Registries
- 44. Problem: Security response times are too long Automate awareness of open source dependencies while operating at DevOps speed
- 45. Managing Open Source Security Requires End-End Visibility INVENTORY Open Source Components MAP To Known Vulnerabilities IDENTIFY License & Quality Risks MANAGE Open Source Risk Policies MONITOR For New Vulnerabilities Automation and workflow Integration with DevOps tools and processes
Editor's Notes
- http://www.istockphoto.com/photo/computer-crime-concept-gm516607038-89059287?st=9174601 http://www.verizonenterprise.com/verizon-insights-lab/dbir/2016/ Every year since 2008, Verizon have published a report on the attempted data breaches occurring within their data centers. For 2015, they found close to 90% of them had either a financial or espionage component to them. This report is well worth the read, and there are a few key findings in this report we should all be aware of. Costs of data breaches are heavily skewed towards legal consultation and forensics, and not to the public components of credit monitoring or lawsuits Despite some vulnerabilities having been public for years, there remain vulnerable components in use Some of those components simply may not have a patch forthcoming for a variety of reasons.
- Despite years of organizations spending energy protecting against attacks, it remains up to the attacker to define what’s valuable. Consider the case of ransomware. A police department in the town next to where I live was subjected to a raonsomeware attack. For roughly 500 USD in bitcoin, the attackers would decrypt the booking and evidence records they had just crypto locked. As an attacker, they likely had no knowledge of who they had attacked or what they had locked up. What mattered was the ransom, and that they had a police organization’s files didn’t factor into the equation.
- Let’s take a little bit of time and look at how an attack is created. Potential attackers have a number of tools at their disposal, and use a number of different tactics. In this case, the attacker wishes to create an attack on a given component. In order to be effective, they have two primary models. First they can actively contribute code in a highly active area of the component with an objective of planting a back door of some form. The hope being that their code will fail to be recognized as suspect given how quickly the area of code is evolving. Second they can look for areas of code which are stable, and the longer they’ve bene stable, the better. The reason for this is simple, old code is likely written by someone who isn’t with the project any longer, or perhaps doesn’t recall all assumptions present at the time the code was written. After all, its been long understood that even with the best developers, assumptions change and old code doesn’t keep up. The goal in both cases being to create an attack against the component, so they test, and fail, and iterate against the component until they’re successful or move on. Assuming they’re successful, they create a deployment tool and document the tool for others. Of course, given the publicity received by some recent vulnerabilities, a little PR goes a long way. Now there are responsible researchers who follow a similar workflow, and they legitimately attempt to work with component creators to disclose vulnerabilities. They too will publish results, but are less interested in creating the an attack beyond a proof of concept. http://www.istockphoto.com/photo/person-in-hooded-sweater-using-a-laptop-on-wooden-table-gm464503138-58544934?st=cf78f31 http://www.istockphoto.com/photo/cloud-computing-gm518556682-90104967
- https://www.cesg.gov.uk/guidance/open-source-software-%E2%80%93-exploring-risk-good-practice-guide-38 If you’re using commercial software, the vendor is responsible for best practice deployment guidance, the notification of any security vulnerabilities and ultimately patches and workarounds for disclosed vulnerabilities. This is part of the deliverable they provide in return for their license fee. If you’re using open source software, that process becomes partly your responsibility. To illustrate the level of information you have to work with, let’s look at a media-wiki maintenance release from December 2015. “various special pages resulted in fata errors” – this clearly is something which needs resolution, but which pages? How do you test? “1.24.6 marks the end of support for 1.24.x” – this is good to know, but I hope it was published elsewhere. “However, 1.24.5 had issues (along with other versions) so it was thought fair to fix them” – This is a good thing, but can we expect this treatment in the future? From the title, we also have a fix for 1.23.x, but what other versions?
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/bugzilla/show_bug.cgi?id=18665 https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT) http://cve.mitre.org/cve/cna.html https://openclipart.org/detail/200681/primary-patch
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/bugzilla/show_bug.cgi?id=18665 https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT) http://cve.mitre.org/cve/cna.html https://openclipart.org/detail/200681/primary-patch
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/bugzilla/show_bug.cgi?id=18665 https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT) http://cve.mitre.org/cve/cna.html https://openclipart.org/detail/200681/primary-patch
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/bugzilla/show_bug.cgi?id=18665 https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT) http://cve.mitre.org/cve/cna.html https://openclipart.org/detail/200681/primary-patch https://www.youtube.com/watch?v=hkryI6eapOA
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/bugzilla/show_bug.cgi?id=18665 https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT) http://cve.mitre.org/cve/cna.html https://openclipart.org/detail/200681/primary-patch https://www.youtube.com/watch?v=hkryI6eapOA
- https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/bugzilla/show_bug.cgi?id=18665 https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547 (published via US-CERT) http://cve.mitre.org/cve/cna.html https://openclipart.org/detail/200681/primary-patch https://www.youtube.com/watch?v=hkryI6eapOA
- Lets see if we can meet these objectives First: lower down risk with minimal effort and operation cost; This suggests automation. The items marked with ‘A’ can be automated Deliver measurable outcomes and business value; yes on team level but not on an enterprise level due to inconsistency within the processes Meet government and regulatory requirements: Assuming correct education is provided to the users then it is possible It is highly likely that teams will learn about security but how well they will practice it – it is a question. Although there is nothing wrong with it but I see a number of concerns with this approach especially from Enterprise level….
- Lets see if we can meet these objectives First: lower down risk with minimal effort and operation cost; This suggests automation. The items marked with ‘A’ can be automated Deliver measurable outcomes and business value; yes on team level but not on an enterprise level due to inconsistency within the processes Meet government and regulatory requirements: Assuming correct education is provided to the users then it is possible It is highly likely that teams will learn about security but how well they will practice it – it is a question. Although there is nothing wrong with it but I see a number of concerns with this approach especially from Enterprise level….
- Lets see if we can meet these objectives First: lower down risk with minimal effort and operation cost; This suggests automation. The items marked with ‘A’ can be automated Deliver measurable outcomes and business value; yes on team level but not on an enterprise level due to inconsistency within the processes Meet government and regulatory requirements: Assuming correct education is provided to the users then it is possible It is highly likely that teams will learn about security but how well they will practice it – it is a question. Although there is nothing wrong with it but I see a number of concerns with this approach especially from Enterprise level….
- Lets see if we can meet these objectives First: lower down risk with minimal effort and operation cost; This suggests automation. The items marked with ‘A’ can be automated Deliver measurable outcomes and business value; yes on team level but not on an enterprise level due to inconsistency within the processes Meet government and regulatory requirements: Assuming correct education is provided to the users then it is possible It is highly likely that teams will learn about security but how well they will practice it – it is a question. Although there is nothing wrong with it but I see a number of concerns with this approach especially from Enterprise level….
- Lets see if we can meet these objectives First: lower down risk with minimal effort and operation cost; This suggests automation. The items marked with ‘A’ can be automated Deliver measurable outcomes and business value; yes on team level but not on an enterprise level due to inconsistency within the processes Meet government and regulatory requirements: Assuming correct education is provided to the users then it is possible It is highly likely that teams will learn about security but how well they will practice it – it is a question. Although there is nothing wrong with it but I see a number of concerns with this approach especially from Enterprise level….
- Lets see if we can meet these objectives First: lower down risk with minimal effort and operation cost; This suggests automation. The items marked with ‘A’ can be automated Deliver measurable outcomes and business value; yes on team level but not on an enterprise level due to inconsistency within the processes Meet government and regulatory requirements: Assuming correct education is provided to the users then it is possible It is highly likely that teams will learn about security but how well they will practice it – it is a question. Although there is nothing wrong with it but I see a number of concerns with this approach especially from Enterprise level….
- Big Idea: According to SAP research, most cyber attacks target the application layer, yet most security investment has been at the network layer. To best protect themselves from security breaches most IT organizations don’t necessarily need to spend more. They just need to spend smarter, investing in the areas that constitute the greatest risk. Question: How does your organization allocate IPSec spending? What % of your budget goes to application security v. network security? Why?
- Hub is based on a 3 part architecture: Scan Client – scans directories and artifact files creating “code prints” that uniquely but confidentially identify the files & directories contained in them Web Application – This is the main user interface and logic center for Hub. KnowledgeBase – This is a repository for open source component, license, and vulnerability information The code prints recorded by the scan client are compared to reference code prints in the KnowledgeBase to identify open source components, versions, and origins. No source or binary code is ever uploaded.
- Big Idea: To manage open source vulnerabilities you need to need to go beyond the testing phase and work throughout the product lifecycle – before, during, and after development. Inventory Open Source – You can’t manage what you don’t see so the first priority is ensuring you have a full, accurate, and current listing of open source used in your applications & containers. Map Known Vulnerabilities – You need a reliable list of known vulnerabilities for your open source and since no single source is complete you need to get this data from multiple sources. Identify Other Risks – Security isn’t the only open source risk to be managed. You also need to manage license compliance and project/code quality risks. You want a single solution that can cover all three. Manage Policies and Remediation Activities – It can be difficult to keep track of your open source risk mitigation efforts. Ideally you want a solution that helps you track these activities. Monitor and Alert for New Vulnerabilities – Since vulnerabilities are often reported months or even years after they enter the code you need a solution that helps you monitor threats to your apps long after they leave development. Big Idea #1: Agile Development is becoming the norm so you need open source vulnerability management to fit seamlessly with your agile tools and processes. This means: You want these capabilities to be automated You want the ability to define policies up front that can automatically flag open source use and security violations throughout the development lifecycle. You want integrations with your other DevOps and Security tools to allow you to control build processes, invoke workflows, and fold open source metrics into reports and dashboards. Question: Which pieces of a potential solution do you have already and which are you missing?