- Can OSS Secure of Our Nation?
- Trust but Verify
- Software Security Perspectives from Joe Jarzombek from The Department of Homeland
- Richard Stallman comments - update
- Followup - Google Code Repository
- Weekly Count
Can Open Source and Free Software Impact the Security of Our Nation?
In this issue of our blog we see it fitting that we focus on our nation and the security of it through open source. The United States was founded on principals of freedom, so it makes sense that now we look towards "free software" to protect her. However, a question that beckons to be asked is, is open source ready to protect the United States' networks, or is the democratic development and decentralized distribution potentially our downfall? There are obvious benefits to open source software, but at the same time there are flaws to it that need to be addressed before it can be considered secure enough for government's systems.
The recent Debian OpenSSL issue has brought much needed attention to the security of open source software. For those of you unfamiliar with the Debian OpenSSL security problem, on May 13th, 2008 http://www.metasploit.com/ announced that OpenSSL distributed in Debian-based systems had a line of code removed with drastically reduced the number of encryption keys and made them predictable. "Instead of mixing in random data for the initial seed, the only "random" value that was used was the current process ID." This affected releases that were distributed between September 2006 and May 13th, 2008. The code was removed because of incompatibility issues between Valgrind and OpenSSL. This security bug would have large repercussions if the government was using one of those Debian releases. Imagine our nation's security reduced to only 32,767 possible encryption keys that were also guessable.
Now one of the arguments for open source is that their are more eyes looking over the code, since the code is openly available to be reviewed and changed by the community. This is true and one of the reasons that this bug was discovered. The open source system of discovering bugs is beneficial in that the number of people reviewing the code is far greater than proprietary software. But as the Debian OpenSSL case shows us, it might take up to two years before it is discovered or at least published. With in the past two years, this bug may have already been discovered and not published, with the finder exploiting the bug for all that time. The problem with community review is that it is a voluntary choice and not an obligation.
With proprietary software, there are fewer people looking over the code, but they are more obligated to find bugs since they are being paid by their employer to do so. I am not saying that proprietary software is necessarily more secure than open source software. The Debian OpenSSL bug could have gone by for two years in a proprietary model just the same, since the number of eyes on the code is drastically less due to the closed source code. So perhaps the solution to open source being used by the organizations are bounty systems, such as the $500 dollar bounty Mozilla offers for bug discovery, for bugs that are found in OSS that they are using. Another solution would be to have proprietary third party software analysis to review the security of open source code. Ultimately using open source code has many time and functionality benefits that would be foolish to ignore, but seeing as it is America's security on the line, extra steps must be implemented to ensure the code is safe to use in exchange for the "free" software.
Trust but Verify (from :http://the-opensource.blogspot.com/2008/07/trust-but-verify.html)
Farewell Address to the Nation, Oval Office, January 11, 1989
"If they persist, pull the plug. It's still trust but verify. It's still play, but cut the cards. It's still watch closely. And don't be afraid to see what you see."
This is the first time that I have had the justification to quote the late President Ronald Reagan to make an obvious point. In the Debian example, the open source community trusted that someone else would look and find the problem. Users believed that the power of community review would reduce the risk of using the software. Users were lulled into a complacency whereby nobody felt the obligation to "verify". Just like when an accident happen, we cannot all just assume that someone else will call 911, offer assistance, get involved. If we accept the socialism of free software, then we must mutually accept the responsibilities associated with the use of such software, or we must impose the obligations of these responsibilities onto the vendors that offer service agreements for such software.
I in no way single out open source software from proprietary software. The point is that just because there is nobody to blame does not mean we cannot look for problems. In the use of open source software, we must be prepared to know how to look, qualify the process by which software is checked and validated, and then centrally and proactively share this information.
Forums exist for the distribution of risk issues, and copious amounts of data has been amassed to allow management of complex environments. Regardless of whether the applications being used are "open source" or proprietary, objective rules and guidelines must be put in place and enforced in order to assure that the power of the community actually means something.
I tend to believe that long past are the days when each user would be forced to review source of any distribution prior to compiling for one's own platform. We as users find it too easy to download the bits, decompress and run. We entrust that in the community of users, someone else will find the problem. This complacency to decentralized responsibility can lead to big problems. The use of open source alternatives to prorietary software is not more risky, it just imposes objective responsibilities and processes that must be abided to in order for open source solutions to continue offering an advantage in the workplace.
Users need to realize that nothing comes free. If we look at the real savings of open source software as that of time, the budget usually allocated to the purchase of commercial solutions can be spent to provide diligent review and management of "open" applications, following documented guidelines, with results of such copious review being continually shared with the community.
Software Security Perspectives with Joe Jarzombek from The Department of Homeland Security (from: http://the-opensource.blogspot.com/2008/07/software-security-perspectives-with-joe.html)
Joseph Jarzombek serves as Director for Software Assurance in the Policy and Strategic Initiatives Branch of the National Cyber Security Division (NCSD) within the Department of Homeland Security (DHS). He hosts and sponsors many public-private collaboration efforts focused on software security. He recently spoke at the AIE Conference on Military Open Source Software, and he shared his perspectives on “Security Considerations in the Use of Open Source Software". The following is my commentary and his words from the conference. Joe Jarzombek also provided the presentation for readers to download.
Ernest Park: The weakness in blind trust of a decentralized community was clearly pointed out with the Debian issue. Without objective mandatory and measurable delivery against processes, software flaws can go unnoticed for periods of time. Joe, is this an example of existing complacency in the use of open source software, and who should accept responsibility for this major security oversight?
Joe Jarzombek: The OSS community still needs a mature and widely-recognized OSS governance regime. If organizations were to adopt OSS, then our acquisition and security personnel need to become more OSS-savvy. They would need to establish an OSS security expert role for verifying and enforcing OSS conformance to organizational requirements and policy.
Ernest Park: It seems like a well organized group with political or financial motivations could wreak havoc on our country using open source software to open the doors to an attack. Is the government concerned about open source applications being used to hide intentionally hidden trojans and coding flaws, such that institutions using such software can be exposed to highly targeted attacks?
Joe Jarzombek: As part of enterprise risk management, organizations should evaluate the trustworthiness of suppliers, and that includes enhanced due-diligence to better understand the pedigree or provenance of the software and the capabilities of the suppliers to deliver secure products and services before acquiring any developers' OSS. Generally the significant OSS projects are maintained by well known developers in the community. They would have to make sure the project team monitored each developer's initial contribution or only his/her later modifications and updates. Their process would also need to include checks/controls to establish developers' identities and trustworthiness. The developers' geographical locations, nationalities, affiliations, ideologies, and loyalties are also easier to obtain with OSS. On OSS projects, it's often possible to discover developers' identities (at least who they claim to be). The same is not true of many proprietary software projects/developers.
Ernest Park: The FLOSS, OSS, FOSS, free software, open source community is a non-centralized ‘socialist’ network. Does the lack of perceived central responsibility pose a higher obligation of risk awareness and mitigation on enterprise users of these applications?
Joe Jarzombek: First, people should understand that many of the issues identified with OSS are equally true for proprietary software. The ability to determine pedigree/provenance should be one factor, but not the only factor, in decision-making on whether or how to proceed with software security evaluation. If there is inadequate information then there needs to be deeper security analysis, vulnerability mitigation and environment-level isolation and constraints to separate “not yet trusted” from “more trusted” software. If there is no pedigree/provenance information then that has sometimes been used as a reason to reject the software especially if it were to be used in national security systems with US only content requirements.
Ernest Park: Do you feel that enterprises are exposing themselves to undue risk if they choose to save money by using open source applications without budgeting for additional resources to manage and oversee such applications?
Joe Jarzombek: Many organizations are already looking into additional resources to manage and oversee applications that they might use. Several companies such as Palamida and Black Duck Software offer discovery programs that will find "hallmarks" in the source code, COTS products, and large software systems. Several companies now offer services that focuses on software security. We have also collaborated with vendors who have made a business out of scrutinizing OSS code, such as Fortify Software, Ounce Labs, Coverity, Cigital, and others. OSS "commodification" potentially provides the best of both worlds: OSS design/code openness and vendor support.
Ernest Park: I have run into some efforts to increase usage of open source within government. Has DHS been involved with these efforts, and is any policy defined to assure high operational security for all applications going forward?
Joe Jarzombek: DHS has sponsored the Vulnerability Discovery and Remediation Open Source Hardening Project in which Coverity, in collaboration with Symantec and Stanford University, evaluated popular OSS to discover and remediateexploitable vulnerabilities.. In this project 40+ OSS packages, including Linux, Apache, MySQL, Perl/Python/PHP were evaluated for vulnerabilities. 11 packages were remediated.
Ernest Park: What should we be doing as a minimum to insure that we are diligent, responsible technology users and proud citizens defending our homeland?
Joe Jarzombek: The broader stakeholder community needs to be security-aware with a better appreciation of just how much our enterprise missions are more at risk because of exploitable software. These risks have to be mitigated during development and in use. We need more security-informed procurements. As consumers we need to exercise more due-diligence in selecting software suppliers and products More comprehensive software diagnostic capabilities need to be used by developers and testers. Also problems that are found need to be reported as soon as possible so that they can get fixed immediately, ideally before code is released. And users should also keep their software up to date by installing the latest patches.
Ernest Park: Has anyone assembled a best practices guideline for using your data sources to more securely and proactively manage our computing environments?
Joe Jarzombek: Our DHS Software Assurance “Build Security In” website offers many publicly available resources which are free to download. BSI at https://buildsecurityin.us-cert.gov/ offers several sound practices from respected practitioners of software security. David A. Wheeler is well know for his contributions in OSS endeavors. He has released papers and projects on OSS and security, including "Open Source Software (OSS) and the U.S. Department of Defense (DoD) – Webinar". If people are interested in further collaboration on software security practices, I would invite the to join us in future Software Assurance Forums and working group sessions which are publicized on our BSI web site under Events.
Ernest Park: We are repeatedly told that the next big attack will come via the internet. What steps can I do to empower myself, my fellow software users and my country to proactively defend, and more predictively manage my environment?
Joe Jarzombek: Software users should, as a minimum, perform a security evaluation on the programs they choose to use that answer these questions:
- Are the software's security assumptions consistent with the security assumptions made by and about the component that the software will implement?
- Can unused functions and interfaces be removed, disabled, or fully isolated without affecting the correct execution of other functions?
- Does the software expose and provide access paths (intended or unintended) to its vulnerabilities?
- What are the common exploitable weaknesses in the code, and what form of static or dynamic code analysis has been performed to determine the resiliency of that code?
The open design and source code availability of OSS should make security evaluation easier.
The Military Open Source Software Conference
April 21-22, 2008
If our numbers seem lacking this week, its because they are. One of our largest sources of data is backed up at the moment. Sourceforge seems to have stopped updating files past June 22. Once SF is caught up on their files to the present, our numbers will catch up to the expected rate. We emailed the maintainers at Sourceforge and that they informed us that they have located the problem. They notified us that he problem will be fixed within the next couple days when they make their next push. For this week, the GPL v3 count is at 2751 GPL v3 projects. The LGPL v3 count remains at 265 LGPL v3 project. And the AGPL v3 number is up 3, bring the total to 120 AGPLv3 projects.
Richard Stallman comments - update
In my last post (http://gpl3.blogspot.com/2008/06/gplv3-one-year-anniversary-edition.html), I included comments from Richard Stallman in an "interview" section. I had hoped that Mr. Stallman would welcome the opportunity to comment on an objective, non-commercial, free effort to openly track adoption rates of GPLv3 related licensing in new software releases over its first year. Instead, through a series of email exchanges, Mr. Stallman indicated more of a philosophical disdain with this information effort, and a dislike for Palamida, the company that continues to generously sponsor this effort.
It seems that Mr. Stallman has clear views with how "free" software needs to be described, referred to, counted.
Richard Stallman: "The free software movement is not merely personal. It is a political movement like the environmental movement, the civil rights movement, etc."
Mr. Stallman contacted me after, asking me to clarify his comments clearly in the context in which they were elicited.
Prior to 6/29/08, I asked a series of questions, and did inform him that his responses would be published in their entirety. From an email exchange between Mr. Stallman and I that followed the publication on 6/29/08:
- ernest park: I can clarify the post. As a note, I was very clear with my intention to publish all of your words, unedited, which I did.
- richard stallman: You invited me to contribute something and said you would publish it unedited. But I did not do that; I instead said why I did not want to.
- ernest park: Redhat, MySQL, Sun, IBM - and others all generously sponsor the existence of open source projects through their proprietary commercial activities.
- richard stallman: I am an activist for free software and freedom; open source is not what I support.
It is clear that Mr. Stallman and I do not see eye to eye. While the various GPL (v2, v3, etc) are specific to the non-commercial aspects of the code, and the availability of the underlying code, aka source code, his position is of "free software being more of a philosophical movement rather than a legal construct around the use and propagation of community developed software.
Followup - Google Code Repository
My views on the licensing restrictions at http://code.google.com/ changed significantly after our talk with Chris DiBona (http://gpl3.blogspot.com/2008/06/gplv3-one-year-anniversary-edition.html). His position of license proliferation is a practical argument. When we see all the licenses out there with prohibitive and vague language, contradictory language, or possibly hidden agendas, perhaps Chris is heading in the better overall direction.
I always think that Creative Commons has always had it right. There is no confusion with what a CC license allows or does not allow. If licenses for open source software were standardized into a simple menu format like CC, how many distinct permutation would really be required? Would the OSS community be better served with less licenses that are clear, with defined interaction and use conditions?
It is a shame that OSI (http://www.opensource.org/licenses) does not require documented interoperability for approval. In this way, even OSI has been party to the unfortunate proliferation of licenses that say similar things, do not cooperate with each other, and create more confusion and complexity for use. As an interesting point, Chris used to be a member of OSI, and consistently lobbied for less approved licenses. OSI approval should really mean much more than the fact that the document passed a spell check (I am being sarcastic).
Chris and I agree on this issue - less licenses with clear terms and documented interoperability will protect the future utility of open source software.
Missing Week, and what's new?
We all took a week off for July 4th. It seems that our time off was aligned well to other issues in open source software. Sourceforge was having issues posting updated information, and as of recently, their information was still queued up. We contacted friends at Sourceforge right away, and they acknowledged that they discovered the issue and things would be back to normal.
Farewell Antony, welcome aboard Edwin
As of this week, Antony Tran is stepping down as Project Manager for the GPL3 Information Search site and blog. Antony has been with the Research Group for over a year, and has handled a number of significant research projects specific to open source software worldwide. He is taking time for himself, and may start the arduous process of interviewing at graduate schools.
The team will miss Antony's contributions and leadership. Starting over the course of the next few weeks, Edwin Pahk will take over project management duties for the information site starting next week. Edwin has been with our team for more than one year after graduating from Berkeley.
Change in format going forward
We accurately tracked GPLv3 adoptions over the last year, and despite quotations and interpretations in all directions, I have to say that the integration of GPLv3 variants in project releases was and continues to be at a steady and growing rate, with over 3000 releases using GPLv3, AGPLv3 and LGPLv3 in the last year, and nearly 7000 "or later" releases. The focus of this information site is moving more into the future of open source - news, security, topical stories. You may have noticed over the course of the last few months the addition of interviews. We will continue the interview format, and are eager to continue to make sure you "read it hear first".
If you wish to participate in an interview, or if you want information from me, please send a note to firstname.lastname@example.org.
LINKS BACK - Please help!
We ENCOURAGE you to copy the content of this site. The Creative Commons license asks only for non-commercial use, and credit. I would like to ask that you also cooperate with the requests herein without my requiring a modified license. Please send me a note if you do so regularly. This site is translated into half a dozen languages weekly that I can find, and on any week, I can find hundreds of partial or complete copies of the site content on other sites.
- Feedburner - RSS of this site is available via subscription
- Email - For those that want the content delivered, email delivery is available. Information about subscribing is on the bottom.
- With the hundreds of copies of this site that go out weekly via subscription, along with the hundreds of copies on other sites, the stats are out of skew. We use Google Analytics to track usage. When the site is copied, the "tracking script" is not copied. As a result, while I can verify hundreds of links and potentially thousands of readers, Google Analytics does not know about it. Please help.
If you are willing to copy and tranlate the content weekly, please let me know - you will receive the content as soon as it is available, and you site will be listed as a translation. I can send you a bit of tracking code so that you get credit for your contribution to the readership of this site
Post your link on the bottom of the blog page.
Send me a note at email@example.com that you are using some or all of the content
I will make sure that we host links to your sites, and we will be able to use your content within this site as well.
The Research Group actively takes submissions from visitors on updates on new GPL v3/LGPL 3 projects. We are amazed at the number of submissions we have gotten to date, but even more so, we are incredibly grateful to over 100 core contributors who have devoted their time and resources at helping us provide up-to-date information.
The Research Group (firstname.lastname@example.org)
For more information, go to http://gpl3.blogspot.com/. To stop receiving these weekly mailings, please send a message to email@example.com with the subject "unsubscribe:gpl3". To start receiving these weekly mailings, please send a message to firstname.lastname@example.org with the subject "subscribe:gpl3".
Our Sponsor, Palamida, Inc.
The GPL3 project, sponsored by Palamida, Inc (http://palamida.com/ ), is an effort to make reliable publicly available information regarding GPLv3 license usage and adoption in new projects.
The opinions expressed within the GPL3 Information Blog are exlusively those of Ernest Park, the subjects interviewed and the contributing authors, and are not intended to reflect the positions of Palamida, Inc and its employees.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License .
Palamida was launched in 2003 after its founders learned first-hand what happens when companies don't have full visibility into the code base of their software applications based on Open Source Software. Their experiences inspired them to create a solution to streamline the process of identifying, tracking and managing the mix of unknown and undocumented Open Source that comprises a growing percentage of today's software applications. Palamida is the industry's first application security solution targeting today's widespread use of Open Source Software. It uses component-level analysis to quickly identify and track undocumented code and associated security vulnerabilities as well as intellectual property and compliance issues and allows development organizations to cost-effectively manage and secure mission critical applications and products.
For more information about FOSS management solutions, go to http://palamida.com/, or send a note to email@example.com.
Please mention the GPL3 site when you reach out to Palamida.