Debates rage across the Internet about the comparative security of Microsoft Windows and Linux-based operating systems. Many people have vested and biased interests in their positions on the matter. Misconceptions born of incomplete knowledge and logical fallacies contribute to the confusion and the heat of the debate. Advertising campaigns attempt to cast their sponsors in the best possible light, and partisan studies use massaged statistical data to produce apparently authoritative and objective, but ultimately no less biased and suspicious, facts to bolster arguments.
Part of the reason for seemingly endless debates without much certainty of conclusions in sight is that many of the attempts to assess security focuses on epiphenomena: they examine the surface features of security without getting into much depth in analyzing the reasons for security characteristics. Part of the reason for this is that, to major proprietary software vendors, the workings of open source development are mysterious and new. As a result, these corporate vendors of closed source software do not always grasp what is happening behind the scenes with regard to security in the open source world.
Another part of the reason is that many of the people involved in the debates are end users with only superficial understandings of what contributes to software security. Even IT professionals often don't understand the effects of software architecture and development process on software security, because IT professionals' skills can exist anywhere in a wide range that often does not include any real understanding of open source development and software architecture, even when it does include a very in-depth understanding of network and system security configuration.
Addressing all the holes in the public knowledge of the underlying influences on software security could be a matter of several thick volumes in print. A cursory examination of a very limited selection from the broader subject area is certainly possible, however, and that's what this article aims to provide.
Ultimately, the Linux vs. Windows security debate is a contest of examples. These examples stand in place of the concepts that comprise a larger, more fundamental question of what the security benefits and detriments are for the open source and closed source development models. This is not only a technical matter. It is also a matter of social factors, and when examined it begins to look suspiciously like a matter for economists and game theorists. By far the more misunderstood of the two approaches in most debates is the open source development model. Let's take a look at some of the facts of how open source development relates to software security.
Security through obscurity
Several security arguments directed at open source software are based on fallacious reasoning. Many of the most irrational, and yet reasonable sounding arguments against open source software center around the myth we call security through obscurity. One commonly heard refrain is "You'll see how secure it is when it's as popular as Microsoft!" Another is "Any old security cracker can see the source code, so it's not as secure!"
The security through obscurity fallacy under girds the majority of arguments against the relative security of Linux-based operating systems and the Mozilla Firefox browser. The truth of the matter is that security through obscurity doesn't really work to provide functional security. It only provides the appearance of equivalent security and, in fact, the open source development community relies on a principle of security that is precisely the opposite. One might call it security through visibility, and it includes two sub-principles of software security: security through transparency and security through popularity.
Security through transparency
Open source software development's security is often questioned on the basis of the availability of its source code to just anyone that wants it. The theory is that by examining this source code, a would-be security cracker can find flaws in the source code that constitute vulnerabilities, thus allowing exploits to be more easily created for those vulnerabilities. There is some basis in fact here, but not in the way people tend to assume.
The truth is that analyzing source code by eye to find and catalog flaws that create a vulnerability you can exploit is arduous and difficult work. If it was as easy as suggested by the notion that open source software is more vulnerable due to the availability of source code, almost nobody outside of Microsoft would ever find vulnerability in Internet Explorer. It is, in fact, such a difficult task for any nontrivial application that it is generally much easier to find vulnerabilities through reverse engineering techniques. These techniques involve poking at a working copy of the application, sending it malformed input and otherwise mistreating it, then examining its stability and output to determine how and when it behaves in a manner its programmers didn't intend.
There may come a day when source code can be fed through another program to determine where it contains flaws more easily than a program can be tested for vulnerabilities through reverse engineering techniques, but by then the same thing will be as easily accomplished with binary executable machine code files without needing any access to the source code itself. After all, what is needed for that sort of analysis isn't information like what the programmer named a given variable or method, but how the algorithms in targeted software are constructed. Machine code is itself, functionally identical to source code prior to being fed through a compiler, after all. The only difference is how readable it is to a given programmer.
Statistically, the facts do not support the assertion that open source software is inherently more vulnerable. For instance, a report by code analysis company Coverity found only 985 bugs in the 5.7 million lines of code in the Linux kernel. By comparison, a study conducted by Carnegie Mellon University's CyLab indicated that a typical commercial, closed source program has between twenty and thirty bugs per thousand lines of code. This bug rate would result in more than 114,000 bugs in 5.7 million lines of code, over 114 times as many as found in the Linux kernel.
An important effect of software transparency in open source software development is often referred to as Peer Review. This is the process whereby, because of the public status of the source code and the fact that programmers working on it do not uniformly serve the purposes of a single controlling entity such as a corporate CEO, the people working on the source code serve to police each others' actions. The rare, but often vehement, argument that a malicious programmer might add a "backdoor" to an otherwise legitimate piece of open source software because the source code is open is clearly refuted by the process of peer review, and by the often stringent and scrupulously applied standards of quality for submitted code that gets accepted into an open source software project's code base. In fact, it could be pointed out that while the source code of open source software is available for public review to find trojan horse capabilities written into a program, proprietary software whose source code is not publicly available can and sometimes does include intentionally added rootkit functionality that will likely only be discovered by accident, after it has been widely circulated, as happened with the infamous Sony rootkit of late 2005.
Security through popularity
The popularity of the Microsoft Windows operating system on the desktop and Internet Explorer as a Web browser is often cited as a reason for the rate of vulnerability discovery and exploits. There is some truth to that. For a closed source, proprietary operating system or Web browser, it is certainly true that greater popularity would tend to bring greater attention from writers of malicious code and other undesirables. Things change when introducing a whole new development model in which popularity is a key factor, however.
With open source software, there is a very low bar to entry for adopting a given piece of software. Because open source software is not necessarily encumbered by any price tag at all, in our increasingly networked world a new operating system installer can be had for no more than the cost of a blank writable compact disk and a few minutes for the download. Depending on your installation method, even the price of the CD can be avoided.
The ease of widespread adoption of open source software adds to the ease of attracting new developers to an open source software project as well. As users increase in number, so too do programmers with an interest in the project. The developers from open source software are drawn from the pool of users, and in addition to this open source software makes good use of casual interest amongst programmers who do not have the time to devote to serious development team involvement, but can easily spare a few minutes now and then to search for, and fix, vulnerabilities and other bugs.
As a result, the number of people looking at a popular piece of open source software for vulnerabilities and other bugs to fix is disproportionately large when compared with closed source software with a limited developer base. That number increases as the number of users increases, as well. The people finding new vulnerabilities for purposes of exploiting them are vastly outnumbered by those finding new vulnerabilities for purposes of fixing them and, even when the people finding the vulnerabilities do not themselves write the code to fix them, they report their findings to people who will do so.
The consequences of this state of affairs are clearly visible, as the fastest recorded Microsoft vulnerability patch distribution after the vulnerability's existence became public knowledge was the WMF library patch earlier this year, with a turn-around time of "approximately nine to 10 days" according to Debby Fry Wilson, the director of the Microsoft Security Response Center. Meanwhile, the Mozilla Foundation routinely produces, tests, and releases patches for the Mozilla Firefox Web browser in less than a week, and patch times for the Linux kernel are often measured in hours rather than days.
This is in large part due to the wide distribution of labor for patch testing: as Debby Fry Wilson said when discussing the WMF patch's quick release, what takes a long time is testing--not patch development. It simply isn't reasonable to expect closed source software to keep up without the ability to test as widely, and often to receive fixes from the testers themselves when testing runs into problems, considering the open source development community's access to a cast of thousands of testers rather than dozens at best.
Proprietary software need not apply
Proprietary software vendors such as Microsoft are beginning to investigate the feasibility of harnessing some of the social forces at work in providing these benefits to enhance the security of their proprietary software offerings. They're discovering that there are some distinct hurdles in their path, however, that appear at this time to be insurmountable. Even the most liberally conceived methods of achieving similar benefits, such as making source code publicly viewable and offering new versions and patches for public testing in unlimited distribution, fail to create the same positive environment for security through visibility that is enjoyed by open source software.
The reason for this is simple: the user base does not have the same investment in the software itself. It is "someone else's software", and they cannot be assured that the future development of the software will serve anyone's needs aside from those of the vendor. The potential loss of any invested time and effort in the software's development and improvement, due solely to the whim of the vendor is a strong disincentive for involvement.
Visibility vs. Obscurity
The open source development community relies on a distinctly different philosophy of software security from that required by a closed-source, proprietary development model. Obscurity can serve security concerns for proprietary software vendors by keeping vulnerabilities out of the public eye long enough for their programmers to develop patches, which safeguards market share by creating a public image of security, even though this can often lead to periods of widespread vulnerability without software users being aware they are at risk. Open source software development provides benefits to visibility that more than make up for any potential security losses incurred, and provides knowledge to software users that they can use to protect themselves until a patch is available. These benefits cannot ever be fully harnessed by proprietary software.
Though the question of visibility versus obscurity as a security characteristic is not the only factor determining software security, it is an important one to understand when examining the open source philosophy of software development, and when analyzing the security characteristics resulting from these two very different software development methodologies.
http://articles.techrepublic.com.com/5100-10877-6064734.html
