Security in the age of open source - Myths and misperceptions

Editor's Notes

• #6: 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.
• #7: 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.
• #8: 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
• #10: 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?
• #12: 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
• #13: 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
• #14: 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
• #15: 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
• #17: 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
• #18: 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
• #22: 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….
• #23: 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….
• #24: 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….
• #25: 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….
• #26: 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….
• #27: 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….
• #33: 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?
• #44: 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.
• #46: 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?