Perhaps in response to the excessive publicity given to the strong security associated with Linux and open source software, it's no surprise that a number of commentators are making a high-profile argument that Linux, just like every other platform, does indeed have security issues. Members of the open source community have always known that Linux is not immune from security threats, so there is no argument there. What is in question is the final conclusion that these commentators are drawing, which is that Linux is less secure than Microsoft Windows.
Fighting for security for the past 20 years
Almost all Linux professionals are also Unix professionals, many of whom have been dealing with online security threats for over 20 years. Remember, the Unix community (and subsequently the Linux community) is the group that first created and still forms the backbone of the Internet. This community was dealing with serious security threats, like the Internet (i.e., Morris) Worm, before Windows NT even existed. Unix users know network and host security inside and out and were the first to implement almost all the intrusion-detection, perimeter-defense, and security-analysis technologies that our industry uses today. Linux/Unix is not invincible from security threats, it's true; but this group has spent the last 20-plus years ensuring that Linux/Unix is more secure than any other system.
Yet the pundits who have raised their voices in recent months, including people who should know better, like Paul Thurrott (of WinInformant), are questioning this generally accepted notion among IT professionals that Linux is more inherently secure than Microsoft's professional operating system platforms. For instance, Thurrott has stated: "In Friday's WinInfo Daily Update newsletter, I mentioned a set of statistics from BugTraq, a reputable security/information provider, that shows how various OSs compare security-wise. The statistics show a surprising trend: When you aggregate all the Linux distributions, Linux, not Windows, has had the most security vulnerabilities, year after year."
The Linux way
As I said earlier, there is no shame in conceding that there are no truly secure operating systems. There is only the ongoing process of trying to keep a host or network secure. Security is like a treadmill. If you don't move forward with security patches, security tools, and revamped system security processes, you'll be flung off the end of it. Oh, and by the way, the crackers have access to the treadmill's speed control knob, and they keep increasing the speed. Needless to say, security is a difficult and continuing effort.
The open source community has worked diligently to fight the good fight against security vulnerabilities. One of this community's basic security philosophies is, "With enough eyeballs, all bugs are shallow." This Linux axiom points to the fact that when a bug becomes an issue, many people have the source code, and it can be quickly resolved without the help of a vendor.
It does, of course, help that most of the security issues that Linux faces are relatively benign, general bugs, and not the exploitable security bugs that wreak such havoc on Windows systems and networks. This point matters greatly when you are looking at the statistics of each security record, because five general bug issues are not in any way the same as five exploitable security bug issues.
A general bug that hits an individual user or site gets reported and resolved. Generally, it doesn't have the same impact as a security bug, particularly one that could exploit remote systems. A general bug (if catastrophic enough) can cause loss of data or system unavailability, but a security bug can cause your system to become "owned" by a cracker. A security bug can mean that you lose data through deletion, have data sent to your competitors or leaked to the trade press, have invalid data inserted into your records, or have customer credit cards stolen and so on.
Further, once vulnerabilities become known, they can spread on backroom IRC channels like wildfire. While you and a few others may encounter a general bug, a remotely exploitable vulnerability has the attribute of attracting penetrative tests against tens of thousands of hosts in a matter of hours, causing far more damage than a general bug.
Finally, catastrophic bugs that affect a large number of systems are few and far between. Most people do not tread the bleeding edge of operating system releases, and widely-used system and subsystem software don't usually harbor catastrophic, general bugs for long. Security bugs, however, can arise in code or in a subsystem, which is widespread and very well entrenched, further accentuating the possible spread of damage.
Because the general bugs can and do affect all operating systems, including Linux, it is clear that even the "with enough eyeballs, all bugs are shallow" idiom isn't perfect. But we do know that the security problem in Linux will be resolved at the source level, a surety we don't have with commercial closed-source or orphaned software.
Perhaps the most important advantage that open source software can provide is that widely used code subsystems that are shown to have security vulnerabilities are fixed and reissued quickly. Microsoft and many closed-source vendors have a woeful history of tardy or nonexistent vulnerability-resolution of their code. This has, thankfully, changed in the past year or two, more than likely due to the torrents of negative publicity poured on these vendors after each security threat announcement.
Now, on to a rebuttal of Paul Thurrott's argument, and a hint to others who have tried to run the vulnerability numbers through the analysis wringer.
Thurrott claims that through the sheer, raw number of vulnerabilities calculated by BugTraq, Linux is less secure than Windows. Thurrott states:
"If you break down those numbers by Linux distribution (despite the fact that Windows 2000 and Windows NT are lumped together), Win2K/NT had 42 vulnerabilities in 2001 (data is through August only), and the leading Linux distribution, Red Hat, had 54. In 2000, Win2K/NT had 97 and Red Hat Linux had 95."
These numbers may, in total, be accurate. I don't dispute them. They appear to be slightly in Windows' favor. However, to my utter amazement, none of these industry observers has taken into account the substantial disparity in system functionality that is shipped on each platform and forms the software basis from which vulnerabilities arise.
I reviewed the broadly categorized functionality packages that ship with Windows 2000 Server, presuming it be a reasonable superset of a generally available Microsoft platform. I counted approximately 120 subsystems in Windows 2000 Server. These include Internet Information Services Web server, Active Server Pages (ASP) Programming Environment, XML Parser, and so on. Now, to compare, I quickly researched a list of subsystems that are shipped with a modern Linux distribution. SuSe had just such a list available for its 7.3 Professional release, so I used it to represent the Linux side of the equation.
The weigh-in? The Linux system had just under 2,600 packages. This means that, based on just this simple analysis, a modern Linux distribution ships with approximately 20 times more functionality in the box than what Microsoft ships with Windows 2000 Server. This is just a count of approximate functionality. With the hundreds of millions of lines of source code shipping for these platforms, a much deeper analysis would be untenable. When one does a quick and dirty calculation based on this new information, Linux, on a per-atomic-functionality basis, can be viewed as being 20 times more secure than Windows. This means that while Linux ships with 20 times as much material, it releases approximately the same number of security alerts as Windows.
Despite playing my own numbers game, the point here isn't to bicker about the statistics behind the research. What our industry needs is for security to be elevated to the front and center of design and coding practices. Any organization, community, or vendor that credibly attempts to achieve this is worth supporting. What should not, however, be condoned are instances where an organization or vendor touts this approach primarily as a cynical marketing exercise, without procuring end results.