451 CAOS Theory 
A blog for the enterprise open source community
Open source security debated
Jay Lyman, February 10, 2009 @ 11:07 pm ETThe debate over the security of open source software is dusting up again with some recent criticism of inherent risk in open source software packages commonly used by enterprises, governments and others. While the criticism from Fortify, based largely on a previous report, comes in response to some UK government indications of an embrace of open source software, I believe that sweeping statements about the security of open source software don’t make much sense.
I’ve also been fortunate enough to speak with a couple of experts who agree: there is open source software that is indeed less secure than it could be, but there are also examples of open source software that has been put to the security test, by years of enterprise use, and has passed (think Linux and Apache here). The other point is that the ‘inherent’ insecurity argument could easily be applied to commercial software, which has its own history of gaping holes and severe vulnerabilities. The bottom line: there is good and bad, secure and risky software in both categories of open source software and proprietary software.
Ernie Park, who headed up his own team’s risk report that featured a nice mix of both open source and proprietary software in use, says the complexity of the software is a major factor in its security and risk. No surprise there, but what is perhaps more interesting is Parks’ assertion that security also seems tied to two other factors: popularity and money. OK, popularity is another one that makes sense — the more widely software is used, the more likely it is to be targeted for security holes. The money behind a software project or product, however, is a far more interesting factor. Basically, Park argues, software that has paid, dedicated experts ensuring its quality and security tends to be more secure than software that comes from a group or community of developers who may not necessarily make their living from it.
Park does, however, still see the benefits of transparency and community, arguing that “a well used and available forum drives awareness to issues, and indirectly facilitates rapid resolution for complex software, regardless of licensing.” While Park laments that open source software has no central vulnerability database or authority, he says that if the larger open source community could get beyond its resistance to the idea of such a body or such control, it could very likely take its transparency advantages and run with them, bolstering the overall security of open source software.
Another perspective comes from David Maxwell, open source strategist for Coverity, which for more than two years has worked with the U.S. Department of Homeland Security in the federal government’s Open Source Hardening Project. Maxwell similarly stays away from sweeping statements about open source as secure, open source as insecure, commercial software as secure or commercial software as insecure. Instead, he says while the quality and security of open source software is generally increasing, that doesn’t mean that the ‘more eyeballs’ argument typically heard from open source proponents is always valid. From Maxwell’s perspective, there is not much difference between open source and commercial software when it comes to integrity, with a range of good and bad in both categories.
As the U.S. and new administration of President Obama contemplate open source software, I expect a similar debate will be occurring over the security of open source. I would hope that it is judged on its merits and its record and put in the perspective of software in general, which is created by human beings and is by no means ever perfect and free of security vulnerabilities, open source or not.
Comments (4) Categories: Software
I have a small clarification for you blog, then a link.
1. There is a direct correlation between reported vulnerabilities and usage. The most used applications have the most consistent and accurate issue reporting, as can be seen by the information reported to the NVD. This is a two part situation. Applications in more “common” use will receive more routine attention. Some applications are on the review list of internal and external testers. The more on the radar an application is, the more likely it is to have regular issues reported. A distinction with reporting is that popular applications do more often have commercial funding, and pay people to test for and find issues. The distinction clarified is that a large user base and popularity leads to something important – corroborating reports of the same issue. If an internal engineer reports an issue, it is valuable, even on a FOSS project. Popularity means that reports may also come from external sources. Those reports can be correlated against the internal ones, thereby providing an objective review of what is going on.
2. Patches are released more consistently by well financed operations. Financial support leads to a more consistent patch release schedule. Good engineers get paid to do what they do. Engineers working on Linux have no had to do so for free, yet Linux is held up as an example of how to do it right. In practice, Linux has among the most vulnerabilities reported against any OS, and when combined with issues against distributions, Linux has the most issues reported against it. The important thing is, when issues are reported, a well funded FOSS project can put engineers against the suspected defect, test, document, and resolve. If a patch is required, a well funded operation delivers the patches faster and more consistently.
3. Vulnerabilities are sometimes and inverse measure to security. Risk has an indirect correlation to issues reported. The problem is that the issues are a communications mechanism. If we point to reported vulnerabilities as a problem, companies will be secretive and mislead information reporting. The process that we want is to have lots of issues reported, and lots of very timely responses. The “risk” is only the component of time from when an issue is reported to the time when a maintainer or vendor responds or posts a patch. The risk is that time during which there is no clear path to safety. THerefore, the biggest risk in software security is using an application which has NO reported issues. This means that nobody is looking, or looking hard enough, or you are using an application with such little user population that nobody will see anything or report it. This risk increases as the complexity of the application increases. I would not be surprised if an icon editor had no issues reported for two years, but would highly suspect the information if a major database had no issues for a time period. Remember, reported issues are just information. Having no response, that represents a risk.
I maintain a 1TB database of information that I crawl from security sites and repositories, and I pull metadata from commercial repositories as well. This very large view across all the data at once gives me confidence that my discoveries are correct, and identify a problem that can be fixed.
Software requires maintenance, even free software. Free software offers “freedom”, not cost savings, although the concept is too often confused. FOSS requires more diligent security and process management because of the fact that no central vendor is accepting responsibility for the software being used. A consumer must be aware of the management responsibilities in using and maintaining software that has no centralized audit trail, and no single responsible party to resolve things.
FOSS means that we should take advantage of the availability of great innovation, but put processes in place and audit diligently.
FOSS is not more secure than commercial. It is inherently less secure. It has the potential to be far better than commercial. It is the realization of that potential that we should strive for.
https://fossbazaar.org/content/foss-ready-usa
Note the most recent comment. It actually reinforces exactly my comments.
Ernie
http://gpl3.blogspot.com
Thanks for posting that clarification and explanation of your perspective, Ernie. I think you highlight some significant issues and opportunities regarding the security of open source software. Interesting that those using software WITHOUT security vulnerabilities should be concerned, rather than confident.
JL
Fortify is a Microsoft ally, so it’s worth disregarding. It’s like hearing that the United States calls Chavez a “dictator” (or not secure) because he doesn’t let the American troops colonialise and rob Venezuela of its oil.
[...] More: 451 CAOS Theory » Open source security deba&#… [...]