Open Source Security

OSS Security

Old N ews

[Oct 28, 2004] eBCVG - Is Open Source Really More Secure

Is Open Source Really More Secure?
Author: Deb Shinde, WindowSecurity
Published: Thursday, 28 October 2004 15:36 GMT

In this article we'll discuss the claim made by proponents of open source software that such software is more secure. Is open source really inherently more secure than closed source commercial software? If so, why? And if not, why do so many have that perception?

The debate surrounding which is best, open source (often free) software or closed source commercial software, continues to rage. Proponents of open source claim that it not only saves money, but is also inherently more secure. The first claim might seem to be a given (although once you factor in learning curve, administrative overhead and support – or lack thereof – “free” software doesn’t always have as much of a TCO advantage as it would seem). The second claim is what we’ll discuss in this article. Is open source really inherently more secure than closed source commercial software? If so, why? And if not, why do so many have that perception?

What is Open Source, Anyway?

Before we can intelligently discuss the differences between open source and proprietary software, we need to clarify what the term really means. Many people equate “open source” with “free of charge,” but that’s not necessarily the case. Open source code can be – and is – the basis for products such as RedHat and dozens of other commercial distributions of Linux that range in cost from a few dollars to a few thousand (RedHat Enterprise Linux premium edition lists at $2499 for Intel x86, up to $18,000 for IBM S/390).

“Open source” also does not mean “unlicensed.” In fact, there are a whole slew of licenses under which open source software is distributed. Some of the most popular include GPL (the GNU Public License), BSD, and the Mozilla Public License. The Open Source Initiative (OSI), a non-profit corporation, has developed a certification process for licenses. You can see a list of open source licenses approved by OSI at http://opensource.org/licenses/.

The name itself tells the story: open source software means the source code (the programming often written in C, C++ or even assembler language) is available to anyone who wants it, and can be examined, changed and used to write additional programming. This is in contrast to “closed” or proprietary software such as Microsoft Windows, for which the source code is a closely guarded trade secret (except when it’s leaked to the public).

When Closed Source Comes Open

Which brings us to recent events: in early February, it was reported that part of the source code for Windows NT 4.0 and Windows 2000 had been leaked to the Internet. Files containing the code were posted to a number of P2P sites and were being eagerly downloaded. The available code comprised only a small portion of the entire code base for the operating systems, but the incident caused a great deal of consternation, both at Redmond and within the IT community.

Microsoft was understandably concerned about its intellectual property rights, but IT pundits played up the security angle. Many unnamed (and some named) “security experts” were quoted as saying the leaks of the source code present a serious security issue, and that hackers could use the information to launch new and improved attacks against the Windows operating systems.

Does This Mean Open Source is Less Secure?

These claims must seem confusing to those who have been listening to open source proponents, who for years have told us that their software is more secure precisely because the source code is readily available to everyone. If having the code “out there” makes Linux more secure, why would the same thing make Windows less secure?

Of course, Microsoft has always taken the opposite stance. During the anti-trust trials, they argued vehemently against the court’s proposed remedy of disclosing their source code based on the security risks of doing so.

Who’s right, then? All other issues aside, what are the security advantages and disadvantages of open source vs. proprietary software? Let’s take a look.

Security Through Obscurity

Vendors of proprietary software say keeping the source code closed makes their product more secure. This reasoning is based on logic; certainly you don’t want to advertise what goodies you have in your house and where they’re located to the neighborhood burglars.

Open source advocates counter that this is merely a form of “security through obscurity,” a concept that’s generally dismissed as ineffective in the IT community. And certainly, by itself it won’t protect you, as a homeowner or as a software vendor. Merely keeping quiet about your possessions might make it less likely that thieves will target you, but you’d be foolish to leave your doors unlocked at night just because you haven’t distributed information about what you own.

Keeping the source code closed might deter some hackers, but the large number of successful attacks against Windows and other proprietary software proves that it certainly doesn’t provide any kind of high level of security.

Speaking of the high rate of attacks against Windows, open sourcers often point to that as “proof” that their software is more secure. However, number of attacks doesn’t prove anything except that Windows is a more popular target. If 90% of the people in the neighborhood put their valuables in a particular brand of safe, the smart burglar is going to spend his time learning to crack that type of safe. The other 10% might use a brand that’s or equal or inferior quality, but they might be successfully attacked less often simply because the product they use is not as ubiquitous.

If you were a hacker, and the majority of systems you encountered ran Windows while a smaller number run a different OS, which one would you prefer to develop attacks and viruses for? Open source proponents are fond of “facts” that show more Windows machines are compromised, more Windows based Web sites are defaced, etc. But in fact, a lower attack rate that’s due to a smaller installed base is just one more form of security through obscurity.

Security Advantages – and Disadvantages – of Open Source

Those in favor of open source say that because everyone has access to the code, bugs and vulnerabilities are found more quickly and thus are fixed more quickly, closing up security holes faster. They also point out that any and everyone is free to create a better, more secure version of the software.

Those on the other side maintain that a closed system in which only trusted insiders debug the code makes it less likely that discovered vulnerabilities will be exploited before they can be patched.

They also point out that there are many reasons (in addition to market share) that are unrelated to the technical security of the software but that can account for a larger number of attacks against proprietary software. One is the nature of the “OS wars” – because open source software has traditionally been more difficult to use, those who gravitate toward it tend to be more technically savvy. The larger number of self-proclaimed hackers who are pro-open source and anti-Microsoft means there are more people out there with the motive and the means to write malicious code targeting Windows systems.

Of course, the open source people can respond that the very fact that Microsoft has more “enemies” makes their software inherently less secure because so many are trying to bring it down.

What’s the Answer?

It’s obvious that you can use both statistics and logic to support either side of the argument. Our discussion started off by asking whether open source software is inherently more secure than proprietary software. That is, does opening the source code in itself make it more secure?

Consideration of the facts makes it obvious that having the code available has both advantages and disadvantages in terms of security. Vulnerabilities may be found – and exploited, if they’re found by the wrong people – more easily, but they may also be fixed – if they’re found by the right people – more quickly. There are many factors that affect the security of an operating system or application, from the code level to the user level. Whether or not the source code is open is probably one of the least important factors.

IS OPEN SOURCE INSECURE - Roaring Penguin Software

To investigate further, I asked Kenneth Brown (author of the M Study) and Gregory Fossedal (Chairman of the AdTI) eight questions, all of which they declined to answer. The eight questions are as follows:

How much did Microsoft pay you?
Do you actually believe anything in the white paper, given the overwhelming consensus in the computer security field that security by obscurity is useless?
Why do you run the Alexis de Tocqueville Institution Web site on the open-source Apache server?
Please check my malware graphs and tell me why that open-source server is bombarded by attacks from closed-source Windows machines.
Please respond to the Mitre Report.
Please explain why NSA distributes security-enhanced Linux but not any closed-source system.
Explain this statement by noted security expert Bruce Schneier:

We pick on [Microsoft] because they've done more to harm Internet security than anyone else, because they repeatedly lie to the public about their products' security, and because they do everything they can to convince people that the problems lie anywhere but inside Microsoft. Microsoft treats security vulnerabilities as public relations problems.
Please explain the web-site defacement statistics which show that closed-source software has a history of defacement totally out of proportion to its market share.

Anti-open source ‘whitepaper’ devastated The Register

Section II is where Microsoft vents its anger. Take a look at this gem:

The GPL is one of the most uniquely restrictive product agreements in the technology industry.

Why does Microsoft... excuse me, the AdTI... say that? They say that because:

The GPL requires that if its source code is used in any type of software product (commercial or non-commercial) for any reason, then the entire new product (also known as the derivative) becomes subject to terms of the GPL open source agreement.

This is not quite true; if you do not distribute your derived product, then you do not need to distribute the source code. But for the most part, the statement is accurate.

But so what? Suppose you derive a product from Microsoft Windows or some other proprietary code. Then you are breaking all kinds of license agreements. Furthermore, proprietary vendors would demand and get the rights to your derived product, leaving you with nothing.

The GPL is no more restrictive than the most liberal of proprietary licenses, and a good deal less restrictive than most. So Microsoft's... excuse me, the AdTI's... complaints are groundless.

Another quote: David Wheeler, publisher and expert in Washington on open source and proprietary source comments, without licensing the source code in a multi-license format, (referring to other more permissive licenses), it is impossible for GPL to work for a proprietary business model.

Perhaps the AdTI misses the point. GPL advocates do not care if GPL'd software can be made to work in a proprietary business model. It's not our problem. There's no God-given right for proprietary software vendors to make money; they have to compete. And if the rules of the marketplace suddenly change and make it difficult for them, well -- tough. Adapt or die. Don't moan.

III. The Myth of a Public Software Community

Section III attempts to debunk the "myth" of a public software community. The AdTI hints that open-source advocates abandon their principles when they smell money:

Widespread support for GPL open source lies in the IT community's frustration with competitive, closed proprietary software. But in fact, it is quite common that programmers experiment with open source until they see an opportunity to capitalize on an idea, then embrace proprietary standards. One could joke that open source has been a bridesmaid but never a bride. The story of the web browser is an example of this reality.

AdTI uses the story of Netscape "killing" the open-source Mosaic. Well, Mosaic was never GPL'd. If it had been, Netscape would have been unable to kill it. Furthermore, AdTI says of Mosaic:

Through a commercial partner, Spyglass, NCSA began widely licensing Mosaic to computer companies including IBM, DEC, AT&T, and NEC.

Conspicuously absent from AdTI's list is another licensee: Microsoft. Yes, Spyglass's browser formed the basis for Internet Explorer. And revealed here is Microsoft's reason to fear the GPL: It cannot make use of the work of thousands of dedicated programmers for free, locking the work up in a proprietary product. It did that with early versions of its TCP/IP stack, derived from the Berkeley stack. But as more free software is GPL'd, Microsoft's cherry-picking opportunities diminish. Isn't it sad?

The AdTI never quite gets around to saying why the open-source community is a "myth". Apparently, the hundreds of collaborators who gave the world the Linux kernel are mythical. Perhaps the outstanding KDE desktop environment was written by unicorns. And one supposes that GNOME, another outstanding desktop environment, was produced by, well, gnomes. Apache -- it's a myth. PHP -- doesn't exist. Mozilla -- pshaw.

Even in my own modest software development, I've had contributions from dozens of people around the world to my software packages. I've had suggestions, fixes, enhancements and pieces of wisdom donated to me which would never have happened in a proprietary development environment.

IV. The Government and the GPL

This is where politicking gets into high gear.

However, the use of the GPL has the potential to radically alter a very successful model for partnership, particularly when most large commercial entities do not readily embrace the GPL.

Once again, the white paper is worried about "large commercial entities." Well, some large commercial entities like HP/Compaq, IBM, Dell and Sun are quite willing to use, produce and/or distribute GPL'd software. To those large commercial entities who wish to stop GPL'd software, I say:"Tough. Adapt or die."

Needless to say, the government could not depend on patches for software glitches to wander in from the public. Likewise, the government could only use open source code that it could independently service in case of an emergency. Agencies without extensive staff to maintain its internal operations cannot afford to use hapless and untested software without accountability, warranties or liability.

This is a complete red herring. Patches don't "wander in" from the public for open-source products. Rather, they come straight from the authors, or sometimes from distributors such as Red Hat. Furthermore, they tend to come in with a lot more alacrity than fixes from commercial vendors.

With open-source, the government at least has an option to be able to "independently service" the software in case of emergency. With proprietary software, the government does not even have this choice. Therefore, the AdTI's objections on this ground are spurious.

Another consideration for the U.S. government is that all source code developed under the GPL could have mirrored availability to the public. This poses unlimited security issues.

AdTI loves this refrain, but has yet to prove it. In my other article, I debunked the myth that source code availability necessarily introduces security issues, and demonstrated that in fact, it can often enhance security. I was interviewed by AdTI for my opinions on the matter; they neglected to include my comments in the paper.

For example, if the Federal Aviation Agency were to develop an application (derived from open source) which controlled 747 flight patterns, a number of issues easily become national security questions such as: Would it be prudent for the FAA to use software that thousands of unknown programmers have intimate knowledge of for something this critical? Could the FAA take the chance that these unknown programmers have not shared the source code accidentally with the wrong parties? Would the FAA's decision to use software in the public domain invite computer hackers more readily than proprietary products?

Again, a ludicrous example. No-one simply sits down and "develops" such an application by starting with free software. Even if the FAA did develop an open-source flight-control application, AdTI has not demonstrated at all that it would have significantly-different security issues than a closed-source one. Sure, AdTI asks a bunch of rhetorical questions. But that's not how one conducts a logical argument. So let's answer the rhetorical questions with some of our own:

Would it be prudent for the FAA to use software that thousands of unknown programmers have intimate knowledge of for something this critical?

Is it prudent for any federal agency to use Microsoft software, given that it is a matter of public record that Russian hackers illegally broke into Microsoft's network and had access to source code? Is it prudent for any federal agency to use software which is not freely-available for peer review? Is it prudent for any federal agency to take the word of a proprietary vendor that its software is secure, given that the vendor is attempting to make a sale?

Could the FAA take the chance that these unknown programmers have not shared the source code accidentally with the wrong parties?

Will the FAA ban the use of Microsoft software, given that it is a certainty that Microsoft source code has been shared "accidentally with the wrong parties"?

Would the FAA's decision to use software in the public domain invite computer hackers more readily than proprietary products?

Will the AdTI comment on why proprietary Web servers seem to be cracked far more often than open-source ones, even though they have smaller market share?

Reverse Engineering

Experts differ on whether the primary focus for security should source code or binary code. Andrew Sibre, a programmer with over twenty years of experiences insists, "Having a license for binaries only gives you a black box : you don't know what it's doing, or how, unless you want to go insane trying to reverse-engineer it with a debugger (illegal under the term of most licenses)" Having the source lets you see what it's doing, how it does it, and permits you to modify it to meet your particular requirements (including security related ones). To this extent, government officials should be concerned that threat may not just be an adversary cracking their system, but inadvertently educating adversaries about their security systems. Sibre continues, "Depending on code without the source is quite similar to depending on a complex mechanical or electronic system without the benefit of shop and parts manuals."

Naturally, having access to source code eases reverse-engineering. However, the vast majority of security exploits are found without access to the source code. As I wrote to Ken Brown, the author of the report:

The entire premise of computer security and encryption is as follows:

A security system must be resistant to attack *even if* the attacker has all the details about how it works. I refer you to: "Applied Cryptography", Bruce Schneier, John Wiley and Sons, Inc, page 3:

"All of the security in these algorithms is based on the key (or keys); none is based in the details of the algorithm. This means that the algorithm can be published and analyzed. Products using the algorithm can be mass-produced. It doesn't matter if an eavesdropper knows your algorithm; if she doesn't know your particular key, she can't read your messages."

I refer you also to: "Practical UNIX and Internet Security", Simson Garfinkel and Gene Spafford, O'Reilly and Associates, pages 40-45:

"... This is especially true if you should find yourself basing your security on the fact that something technical is unknown to your attackers. This concept can even hurt your security."

I refer you to an Internet draft on security through obscurity: http://www.ietf.org/internet-drafts/draft-ymbk-obscurity-00.txt

A few more links on why security through obscurity does not work:
http://www.treachery.net/~jdyson/toorcon2001/ http://www.counterpane.com/crypto-gram-0205.html http://online.securityfocus.com/columnists/80 http://www.vnunet.com/Analysis/1126488

Is Reverse-Engineering That Hard?
Before I started Roaring Penguin Software Inc., I worked at Chipworks, a company which does reverse-engineering for a living. From first-hand experience, I know that hardware and software security can be broken more easily than most vendors believe, and much more cheaply, too.

Back-Doors Ken Brown raises the old back-door bogeyman:
Another security concern is that the primary distribution channel for GPL open source is the Internet. As opposed to proprietary vendors, open source is freely downloaded. However, software in the public domain could contain a critical problem, a backdoor or worse, a dangerous virus.

The following material is taken straight from my other article, where I already covered the back-door issue: In fact, there have been some trojans placed in open-source software. They have usually been discovered and neutralized very quickly. By contrast, closed-source products have a sad history of spyware, "Easter eggs", and questionable material, placed by people who have (presumably) been "screened." In fact, one of Microsoft's own security updates was infected with a virus, something which (to my knowledge) has never happened in the open-source world.

An interesting back-door was one in Borland's closed-source Interbase product. This back-door lay undetected for years, but was revealed within weeks of the product being open-sourced.

And another interesting little "easter egg" is on the AdTI's very own Web site.

Questionable material in Microsoft software may have helped spur a Peruvian bill to promote free software in government. The author of the bill says that open-source software provides a better guarantee of "security of the State and citizens" than proprietary software, an analysis which is 180 degrees out of phase with the AdTI Study.

The real "victims" of the GPL

The government's productive alliance with private enterprise is also relevant particularly when its decision to use GPL source code would inherently turn away many of its traditional partners. Security, as well as other impracticalities make GPL open source very unattractive to companies concerned about intellectual property rights. In effect, the government's use of GPL source code could inevitably shut out the intellectual property based sector.

The Government must choose software to maximize national security and minimize government expenditure. It owes absolutely nothing to the "IP-based sector" or any other corporation. What was it I said before? Oh, yes: "Tough. Adapt or die."

This has a number of ramifications. Immediately, it would limit the number of qualified vendors to choose from to deliver products.

Tough. Adapt or die.

The GPL's wording also prevents the equal use of software by members of the IP community and the GPL open source community.

This is a lie. If the "IP community" (whatever that is) respects the terms and conditions of the GPL, it's as free as anyone else to use and distribute GPL'd software. If it doesn't like the terms of the GPL, that's the "IP community's" problem, not the GPL's problem.

A worse consideration is that use of GPL could inadvertently create legal problems. IP community members could argue that the government's choice of open source is restrictive and excludes taxpaying firms from taxpayer-funded projects. Adverse impact would include a discontinued flow of technology transfer from government-funded research to the technology sector. Without value, it becomes highly likely that government funding for research would slow as well.

Here, AdTI is delivering a veiled threat on behalf of Microsoft. First of all, if "IP community members" could argue that, they already would have. They have not made the argument because they know it is specious. In fact, there's a very good argument for requiring the fruits of government-funded research to be GPL'd so that all citizens can benefit.

Furthermore, the "IP community members" have benefited from government research as much as (or more than) government has benefited from private research. So to pull out of government partnerships out of pique over software licensing would only hurt proprietary vendors and no-one else.

V. Intellectual Property Left

This is a rewording of "Free Software is Communism" and merits about the same amount of serious attention.

U.S. intellectual property (IP) statutes have been a beacon for inventors around the world. The U.S. model for motivating, compensating and protecting innovators has been successful for almost 200 years. GPL source code directly competes with the intellectual property restrictions, thus it is vital to analyze its impact.

The GPL does not in any way "compete" with U.S. copyright law. It uses U.S. copyright law in a perfectly legitimate and reasonable way.

There are two groups of programmers that contribute to the open source community. The first group consists of professionally hired programmers by day, who freely contribute code. The second group consists of original equipment manufacturers (OEMs) that are hiring open source programmers for their products. However, open source principally perpetuates itself because there is an avid pool of experts and enthusiasts willing to spend their spare time to provide fixes and modifications to open-source software. This volunteer system works well as an academic model, but not as a business one.

Who cares about business models? We have Linux, Apache, Mozilla, Gnome, KDE, Perl, Python, PHP, FreeBSD, OpenBSD, NetBSD, and so on in spite of the supposed lack of a business model. What we see here is more whining from proprietary vendors about how free software is hurting their business model. Let's hear the refrain: "Tough. Adapt or die."

As mentioned earlier, open source code is not guaranteed nor does it come with a warranty.

Neither does most proprietary software, so this is a red herring. If you want a warranty, most open-source vendors will be happy to provide one if you pay for it.

Open source products are often distributed without manuals, instructions or technical information. While a commercial developer is obligated to produce manuals, diagrams and information detailing the functionality of their products, open source programmers are not. In addition, open source developers cannot be expected to create software manuals with the vigor of private firms that are obligated to produce them. Producing technical specifications (in soft or hard copy format) is time-intensive and expensive. But this is not just a customer service issue.

Some open-source software comes with poor documentation, just like some proprietary software. Other free software comes with excellent documentation. It's a matter of customer choice: Choose software that has what you need.

All of my free software products come with complete manual pages. Most serious developers do not consider software finished until the manuals are finished.

Innumerable questions surround the distribution of technical information in the copyleft environment, particularly because the Free Software Foundation has a copyleft license for its documentation as well. Issues include: Who should have the right to alter software manuals? Who is the final editor or is there one? How should changes be regulated? Are manuals copyright protected documents? What is the process for making changes? What body regulates these changes? How can organizations guarantee that information in manuals is always accurate?

More rhetorical questions. With proprietary software, if the manuals are inaccurate, you're out of luck. With free software, you at least have a chance to correct them.

Again, we see the unease of the proprietary vendors who want bodies to "regulate" changes. They are unable to wrap their minds around the new reality of free software. Rather than changing their ways, they dig in their heels. They may need another reminder: Tough. Adapt or die.

Today, software impacts a firm's financial health in an intimate fashion. It becomes unrealistic for a firm to depend too much on the trust of an anonymous community that does not have anything at stake financially to keep important technical documents current.

On the contrary, it is imperative that businesses rely solely on free software for access to critical information. Only in this way can they guarantee access to their data, and not be held hostage by proprietary file formats and proprietary vendors. To quote Dr. Edgar David Villanueva Nunez, a Peruvian legislator:

To guarantee the free access of citizens to public information, it is indispensable that the encoding of data is not tied to a single provider. The use of standard and open formats gives a guarantee of this free access, if necessary through the creation of compatible free software.

To guarantee the permanence of public data, it is necessary that the usability and maintenance of the software does not depend on the goodwill of the suppliers, or on the monopoly conditions imposed by them. For this reason the State needs systems the development of which can be guaranteed due to the availability of the source code.

To guarantee national security or the security of the State, it is indispensable to be able to rely on systems without elements which allow control from a distance or the undesired transmission of information to third parties. Systems with source code freely accessible to the public are required to allow their inspection by the State itself, by the citizens, and by a large number of independent experts throughout the world. Our proposal brings further security, since the knowledge of the source code will eliminate the growing number of programs with *spy code*.

In the same way, our proposal strengthens the security of the citizens, both in their role as legitimate owners of information managed by the state, and in their role as consumers. In this second case, by allowing the growth of a widespread availability of free software not containing *spy code* able to put at risk privacy and individual freedoms.

In fact, Villanueva's eloquent and well-written letter handily demolishes most of AdTI's premises and conclusions; it's well worth a read.

More on Reverse Engineering

The reliance on reverse engineering is probably one of the biggest conflicts between the IP and the GPL open source community. To keep GPL products relevant and up to date, GPL enthusiasts must perpetually reverse engineer intellectual property.

Reverse-engineering is required only if hardware manufacturers keep the details of their software/hardware interfaces secret. The vast majority of hardware manufacturers do not keep them secret. Some which do keep them secret provide (binary-only) drivers for free software systems. Reverse-engineering is necessary only for the small minority of hardware devices which are secret.

Reverse engineering has a number of implications. It harbors very close to IP infringement because and has staggering economic implications.

Reverse-engineering is perfectly legal. In fact, the European Union has a law guaranteeing the legality of reverse-engineering for the purpose of creating compatible software or devices. AdTI implies that reverse-engineering is "close to IP infringement", but they never say why (and their sentence doesn't even parse.)

If software is freely re-engineered, it will inevitably impact the value of software on the market. If the price of software is adversely impacted, salaries and inevitably employment of software programmers would be negatively affected as well.

This is correct. If software is freely re-engineered, it destroys monopolies and brings back a sense of free market to the industry. Yes, software prices go down. And yes, consumers benefit.

The whole paragraph is simply a thinly-hidden Microsoft lament about the success of products like Samba which enable companies to run Microsoft-compatible file sharing without exorbitant Microsoft licensing fees.

VI. Is the GPL Cost-Beneficial?
This is a restatement of the tired old "TCO" straw-man.

Discussing the economic implications of open source, Andre Carter, President of Irimi Corporation, a technology consulting firm in Washington comments, "The question of open source code is about whether the software developer wants to make available to the world the blueprint of what they built or simply the benefits of what they built. The notion of open source software has nothing to do with free software. The purchase price of computer software is only a fraction of the total cost of ownership. So even if the price tag reads free , it can end up being more expensive than software you buy. This is especially true for the typical consumer. If it requires technical know-how to operate, doesn't offer built-in support, and demands constant attention, it won't feel free for very long."

Lot's of "if's" and weasel-words in there. If it requires technical know-how to operate, etc, etc. Nowhere does Carter say that free software does in fact require any more technical know-how than proprietary software. Furthermore, proprietary software often has hidden costs which can come back later to haunt you.

The success of an A-Z open source environment would expectedly impact the software sector as a viable entity. If software is freely available, but PC s, servers and hardware maintain their value, we can only predict that the value of software companies will plummet. Hardware will come with more and more free software. Second, we can only expect that the revenues and value of the software sector will transfer to the hardware sector. Although the software sector has seen growth almost every year, it is questionable whether the GPL model will enable the software industry to continue its exceptional growth particularly when the growth in the software sector is tied to proprietary products, something the GPL is anxious to eliminate.

In the 1800's, black-smithing was a pretty good profession. In the 1960's and 1970's, 8-track tapes did a pretty good business. The fact is that the black-smith industry and the 8-track tape industry failed to heed the iron rule of the market: Adapt or die. If free software means the death of proprietary software vendors, it will be on those vendors heads who fail to adapt.

Businesses must be concerned about the perception of the GPL. For example, experts assess the value of intellectual property when completing valuations of firms. Because GPL open source literally erases the proprietary and trade secret value of software, it can be expected that firms concerned about valuations will be very concerned about using GPL open source.

This is only of concern to firms producing software. The vast majority of firms consume software, and for them, in-house software production is a cost, not a revenue source. For the vast majority of firms, free software will save them lots of money. For those few firms planning on building a business model around proprietary software, I offer my old refrain: Adapt or die. What's good for proprietary software vendors is not necessarily good for the citizen.

There are all types of consumers with ranges of needs and abilities. The guys in the lab at MIT don't need install wizards, plug and play drivers, voice based technical support and big picture manuals as part of their software. However, the elderly couple e-mailing their grandkids or the mother of two managing accounts on a PC in the kitchen does.

Carter clearly has a stereotyped view of consumers. My elderly parents, who enjoy e-mailing their grandkids, use only free software. They are quite happy to use Linux and Netscape. Furthermore, the choice of free software eases my support burden: If my parents need help, I can SSH into their machine and fix it remotely. With all of Microsoft's "wizards" and other gimmicks, they still do not provide a convenient means for remote administration on their consumer-level systems.

People believe free software is hard to use because they've never used it. Just as the AdTI showed that people who've actually worked with MCSE's have a higher opinion of them than people who haven't, people who've actually bothered to use free software have a higher opinion of it than people who haven't.

VII. GPL Open Source and the Courts

Once GPL code is combined with another type of source code, the entire product is GPL. Subsequently, this change could occur deliberately, but it could also occur accidentally. There are unlimited scenarios for accidents to occur, the license could be lost in the source code's distribution, or maybe unreadable due to a glitch in its electronic distribution. Another potentially litigious issue is whether the use of GPL tools used to manipulate code subject software to the GPL. Theoretically, a GPL tool could subject new software to GPL restrictions. This too will have to be interpreted by a judge. Regardless, unknowing users of GPL might have one intention for use of the license and find out later that it inadvertently infringed upon copyright protected work. Legal questions relevant to such an event intersect the legal arenas of intellectual property rights, contract law and liability.

AdTI is very good at offering up red herrings. Let's suppose you "accidentally" included part of Microsoft Windows in a product. Do you suppose Microsoft would be easier on you than copyright holders of a GPL'd product?

The fact is that any software license has terms and conditions which must be obeyed. The GPL is no different; if you do not like its terms, don't use GPL'd software. Microsoft's agenda is transparent here.

The proprietary software industry entreats you to diligently track licenses, and offers harsh retribution against those who violate their licenses. Most GPL violations are settled amicably, and those which result from an accident are usually settled merely by removing the offending code from distribution.

The rest of Section VII is simply speculation and not even worth commenting on.

VIII Conclusion

Open source as a development model is helpful to the software industry. For example, software distributed under the BSD license is very popular. The BSD license (see Appendix 9) enables companies, independent developers and the academic community to fluidly exchange software source code.

English translation: The BSD license is good because it allows corporations to benefit from other people's work without offering them any compensation, and without having to allow third parties to benefit from derived work.

The GPL's resistance to commonplace exchange of open source and proprietary has the potential to negatively impact the research and development budgets of companies.

English translation: The GPL doesn't let corporations benefit for free from others' work.

The GPL has many risks, but the greatest is its threat to the cooperation between different parties who collaborate and create new technologies. Today, government, commercial enterprise, academicians, etc. have a system to converge. Conversely, the GPL represents divergence; proposing to remove the current infrastructure of intellectual property rights, enforceable protection and economic incentive.

English translation: The GPL threatens Microsoft's business model. You know my response by now: Tough. Adapt or die.

While GPL advocates are quite active in their promotion of copyleft, few would disagree that its widespread adoption would present a radical change to an industry sector responsible for almost 350 billion dollars in sales annually worldwide (see Appendix 10).

Few would disagree that the automobile all but wiped out blacksmithing as a profession. Few could argue that cassettes didn't decimate the 8-track market. Few would be surprised at my response: Tough. Adapt or die.

AdTI's Numbered Points and my Counterpoints

1- Engineering software has become considerably complicated and rigorous. It is not unusual for software to include millions of lines of source code. If the incentive to develop software is changed, we can subsequently expect the quality and efficiency of software to change.

Yes, with luck, we'd expect the quality to improve. The security records of systems like OpenBSD, Linux, and FreeBSD are vastly superior to that of Windows. While there is no real cause-and-effect relationship, empirical evidence suggests that open-source software is more reliable and of higher quality than most commercial-grade proprietary software.

2- There remains considerable differences within the GPL open source community. It is questionable whether these groups will continue to be proponents of the GPL in its current form or opt for changes in the immediate future.

Even if true, this point is irrelevant. Once software has been licensed under the GPL, the license cannot be retracted. Your rights cannot be withdrawn retroactively (unless you violate the license), unlike some proprietary software licenses.

3- Open source has successfully been used in proprietary software. In addition, academic and government projects have been successful particularly because of commercial interest. Private enterprise offers unique efficiencies for the success of government funded research.

Simply another attack on the GPL. Nothing worth reading; let's move on.

4- Open source GPL use by government agencies could easily become a national security concern. Government use of software in the public domain is exceptionally risky.

A bold assertion, and totally unproven. This assertion is contradicted by empirical evidence. Also, the NSA seems quite comfortable with the security of GPL'd software.

5- Reverse engineering, perpetuated by GPL proponents, threatens not only the owners of intellectual property, but also the software industry itself.

This is an out-and-out lie. Reverse-engineering is critical for the continuation of a healthy software industry. Without legitimate reverse-engineering, there would be no market forces to oppose the development and maintenance of monopolies, and the software market would become even more unfair than it is today.

Attempts to ban reverse-engineering are simply money-grabs by greedy monopolies who wish to hang on to their power.

6- Use of GPL open source creates a number of economic concerns for firms. For example, the valuation of a software company could be significantly effected if it uses source code licensed under the GPL for the development of its products.

If that is of concern (and it is not for the vast majority of corporations), then the corporation is perfectly free not to use GPL'd software.

Using proprietary software for development of products can also significantly lower a company's valuation, especially if the owner of the original proprietary software demands royalties or part-ownership of the resulting IP.

7- The courts have yet to weigh in on the General Public License. Without legal interpretation, the use of the GPL could be perilous to users in a number of scenarios.

If corporations have concerns about legal interpretations of the GPL, they should consult qualified lawyers. IBM, for example, has a massive and top-notch legal team, and they seem to have no qualms about using, creating and distributing GPL'd software. If the AdTI would give us concrete examples of legal concerns, we could discuss them, but as it is, all we are given is conjecture, hand-waving and supposition.

Roaring Penguin's Conclusions

The AdTI claimed that the GPL is "acquisitive", yet fails to note that even the most liberal of proprietary licenses is far more restrictive and places far more encumbrances on derived products than the GPL (if, in fact, it even permits derived products in the first place.)

The AdTI says that the free software community is a "myth", but fails to explain the tens of millions of lines of high-quality code produced by this mythical community.

The AdTI promised to show how using GPL'd software could threaten security, but failed to deliver. Rather, Microsoft's own Jim Allchin admitted under oath that flaws in Microsoft software, if disclosed, could endanger national security.

The AdTI claims that free software damages members of the "IP community" (by which it means proprietary software vendors), but then fails to show how such damage occurs. Even if free software does damage proprietary software vendors, AdTI fails to show why that is a bad thing for citizens in general.

AdTI raises the hoary old "Total Cost of Ownership" issue, but does not demonstrate that proprietary software is more cost effective. AdTI ignores studies like the one from CyberSource or even Roaring Penguin's own case studies in Free Software in the Real World.

The entire AdTI study is a commercial funded by Microsoft, whose sole aim is to counter the growing adoption of GPL'd software. The report contains nothing constructive or useful. It is a sham.

Other press, commentary and related links:
MS-funded think tank propagates open-source lies, The Register.
Analysis: Microsoft vs. open source battle gets political, InfoWorld.

What Sla$hdot DOESNT want you know (Score:-1, Offtopic)
by Anonymous Coward on Sunday April 18, @11:18AM (#8897126)

An analysis of hacker attacks on online servers in January by security consultancy mi2g found that Linux servers were the most frequently violated, accounting for 13,654 successful attacks, or 80 per cent of the survey total. Windows ran a distant second with 2,005 attacks. A more specific analysis of government servers also found Linux more susceptible, accounting for 57 per cent of all breaches [zdnet.com.au]

[Nov 20, 2003] Open source no panacea for security

Conventional wisdom says viruses, bugs and other security problems could be more rapidly cleaned up if only the world would move to an open-source model. Security experts speaking at Comdex disagreed.

"I think open-source software is slightly less secure," said Gary McGraw, chief technology officer of Cigital, who sat on a panel on security problems at the five-day conference in Las Vegas.

"Open-source developers say that there are a million eyes looking at it, but I would rather have one set of good eyes," McGraw said. "There is this boring job that no one wants to do."

Still, despite the problem of having no one specifically in charge of security, Linux so far has avoided many of the virus and worm problems. "There is this nice, big fascist control" imposed by Linus Torvalds over the addition of new features, McGraw said.

McGraw also pointed out that the complexity of software code, especially Windows code, is creating security problems. In 1998, the CERT Coordination Center--the security experts at Carnegie Mellon University--reported 262 vulnerabilities. The number grew to 417 in 1999, to 2,437 in 2001 and to 4,129 last year. At the same time, Windows has added millions of lines of code.

"More lines, more code," he made the audience of 300 chant.

[Mar 20, 2002] Building trust into open source CNET News.com By Robert Lemos

In the past three months, the open-source community has been given a wake-up call.

While Microsoft has concentrated on reviewing its flagship Windows source code as part of a new focus on security, Internet watchdogs have released the details of three widespread flaws in open-source applications usually shipped with the Linux operating system.

The flaws could compromise the security of computers on which the applications are installed, prompting some developers to urge the open-source community to take another look at popular code. But most fear the majority of members won't bother.

"No one is doing auditing," said Crispin Cowan, chief scientist at Linux maker WireX Communications, one of several companies selling a version of the OS with additional security options. Cowan is the founder of Sardonix, a Web site aimed at organizing groups of people who want to review major open-source software.

"Reviewing old code is tedious and boring and no one wants to do it," Cowan said.

With Microsoft launching a major security initiative in response to recent criticism, some fear that Linux and open-source developers have become complacent in the commonly held belief that open-source programs are more secure.

This year offered several reasons to question that belief.

In February, a flaw found in the popular scripting language PHP left as many as 9 million Web sites vulnerable to attack. Though the number of vulnerable sites could be as low as 100,000 and the flaw is hard to exploit, the software bug resembles the Web software slipup that left Microsoft servers vulnerable to the Code Red virus.

Gartner analysts Richard Stiennon and John Pescatore say that despite new attention given to software security, no software--whether proprietary or open source--will ever be 100 percent secure.
see commentary

In March, another flaw, in the omnipresent Zlib compression library, left Linux systems potentially vulnerable to attack, though no program exploiting the hole has surfaced.

And in mid-March, a bug in the OpenSSH communications encryption program, commonly used to secure communications to and from Linux computers, left many of those machines open to attack.

The spate of flaws has not gone unnoticed by the open-source community's more vocal members.

"I see a lot of bad software being done," said Theo de Raadt, founder and project leader for the open-source Unix variant OpenBSD. "There is a lot of politics and inaction causing people not to make changes that makes their software better."

The "many eyes" theory
Open-source software's main claim to security is that because anyone can view the source code, developers can constantly look for bugs and fix them. And with a broad cross-section of expertise in the developer community, programmers with specific strengths can look for hard-to-understand, "deep," bugs and fix what others might miss.

In his essay on the open-source movement, "The Cathedral and the Bazaar," developer Eric Raymond wrote, "Given enough eyeballs, all bugs are shallow."

De Raadt led a team of OpenBSD developers on just such a review, cleaning up the source code for the Unix-like operating system and replacing functions that were known to be insecure with more robust substitutes.

Yet, the "many eyes" theory, as it is known in the open-source world, doesn't work so well in reality, said WireX's Cowan.

"It does not assure that many eyes are actually looking at the code," Cowan said. "In fact, it is likely that 'rock star' code that is hip to work on gets adequate attention, while the other 90 percent languishes, in many cases never even seen by anyone but the code's authors." And much of this unsexy code forms the foundation of Linux.

Cowan hopes his Sardonix site will become a central registration point for auditing efforts, but for now, Linux and open-source software must rely on developers feeling obligated enough to commit to the drudgery of vetting source code for software bugs.

After security researchers found the flaw in the Web scripting language PHP, a group of programmers decided to start auditing that popular project's code.

"It's difficult to introduce new features and review the existing code at the same time," said Frank Denis, a part-time systems administrator for a French Internet service provider and leader of the PHP code-auditing project. "It's why we are trying to give a hand on that point. We won't introduce any new features, but we will fix potentially dangerous code."

A central process to find bugs, such as Microsoft's Trustworthy Computing initiative, will never catch all flaws in open-source software, Denis added.

"To break into your server, script kiddies will try totally unconventional tricks that have no chance of being part of any initial validation procedure," Denis said, referring to the class of online vandals who are not as technically adept. "The result of (our) different approaches will give a more extensive audit than any strict guidelines. That is the strength of free software: Everyone can put his own brick in the wall."

Polishing the software
Despite the security problem with his own project's code, Jean-loup Gailly, chief software architect for Vision IQ and the co-creator of the Zlib compression library, stressed that Linux's development process still creates more secure code.

"Open-source programs are subject to much more scrutiny and, in case of problems, fixed much more quickly than closed-source programs," Gailly said. "Apache is not more popular than Microsoft IIS (Internet Information Server) by accident; one of the reasons is that it is more secure."

An additional layer of polish is put on the source code by companies and organizations such as Red Hat and Debian, which package their own Linux distributions, Gailly added.

Linus Torvalds, a senior engineer at chipmaker Transmeta and the creator of the Linux kernel, thinks the open-source development style works well.

"Most (code review) by far is simply people looking at code, often for some other reason that had nothing to do with formal auditing," Torvalds said. "I personally like it that way, and it's proven to work pretty well in practice."

Moreover, rather than seeing a threat from Microsoft's new focus on security, Torvalds believes the move shows how weak the company's security used to be. Microsoft wouldn't provide an executive for comment on the issue.

"Let's face it," Torvalds said. "Microsoft did their initiative because they've been so bad at security in general. They fix bugs when somebody drives a truck through them and they get embarrassed enough. Get embarrassed (often) enough, and you start creating 'initiatives'--whether in politics or in commercial software."

He continued: "In the open-source community, the community has so far been pretty good at policing itself without the embarrassment. Do bugs happen? Yes, of course. But do they get found and fixed without a new virus of the week that costs a few billion dollars of user time? You bet."

Flaw leaves Linux computers vulnerable

March 11, 2002

Seeking signs of Microsoft security push

March 4, 2002

Scripting flaw leaves sites vulnerable

February 27, 2002

Basic network flaw threatens Net's users

February 12, 2002

Get this story's "Big Picture"

[May 30, 2002] BW Open Source Software May Offer Target for Terrorists, According to Study by Alexis de Tocqueville Institution's Committee for the Common Defense

WASHINGTON--(BUSINESS WIRE)--May 30, 2002--Terrorists trying to hack or disrupt U.S. computer networks might find it easier if the federal government attempts to switch to "open source" as some groups propose.

"Opening the Open Source Debate", a soon to be released white paper by Alexis de Tocqueville Institution details the complex issues surrounding open source, particularly if federal agencies such as the Department of Defense or the Federal Aviation Administration use software that inherently requires that its blueprints, source code and architecture is made widely available to any person interested - without discretion.

In a paper to be released next week, the Alexis de Tocqueville Institution outlines how open source might facilitate efforts to disrupt or sabotage electronic commerce, air traffic control or even sensitive surveillance systems.

Unlike proprietary software, open source software does not make the underlying code of a software confidential.

"Computer systems are the backbone to U.S. national security", says Fossedal, chairman of the Alexis de Tocqueville Institution and its Committee for the Common Defense, which will release the study. "Before the Pentagon and other federal agencies make uninformed decision to alter the very foundation of computer security, they should study the potential consequences carefully."

ZDNet Tech Update

March 20, 2002 Flaws turn security spotlight on open source software
With security flaws in widely used open-source applications coming to light, even open source insiders are beginning to question the community's ability to cope. "I see a lot of bad software being done," says Theo de Raadt, founder of the OpenBSD open-source effort.

Wide Open News -- Security Through Obscurity

... Associates. The theory of open source security is simple, and it is endemic throughout the entire open source community. The theory ...

News: Too much trust in open source?

... theory Open-source software's main claim to security is that because anyone can
view the source code, developers can constantly look for bugs and fix them. ...
zdnet.com.com/2100-1104-864256.html - 59k - Cached - Similar pages

[Mar 10, 2001] Information Security MagazineBY PETE LOSHIN OPEN-SOURCE SECURITYMarch 2001OPEN SOURCE UNDER THE HOOD. Columnist PETE LOSHIN (pete@loshin.com) is a senior editor-at-large for Information Security. He produces the Internet-Standard.com Web site and has authored more than 20 books on Internet protocols and security.

Vendors are increasingly including open-source components in their commercial products. What impact does this trend have on product security?

The days are long gone when all you needed to start your own software company were a compiler and a computer. Creating commercial off-the-shelf (COTS) products from scratch in today's market is a daunting task for any but the biggest software companies. Smaller vendors have to compete with the likes of Microsoft, Sun and Cisco, with only a fraction of the resources.

Almost no one can afford to build their own new products from scratch anymore, and the problem is magnified for vendors of network appliances: They've got to deliver a functional, competitively priced server, including software and hardware, while still turning a profit. Vendors of other products, from operating systems to software suites to end-user workstations, are feeling the pinch as well.

Considering this environment, it's not surprising to find vendors increasingly turning to open-source code when creating new products. Yet buyers may not always be aware that inside their shiny new firewall lurks an open-source OS, such as Linux or FreeBSD. Network security appliances designed to do firewalling, intrusion detection and other security functions often rely extensively on open-source OSes and utilities. But many other products include open-source components as well. Apple's new Macintosh OS X, for instance, is based on Free BSD 3.2 and the Mach 3.0 project from Carnegie Mellon University. Apache, BIND, Sendmail and Perl are all widely used in both commercial and non-commercial products.

Among the obvious reasons developers turn to open source are cost and security. Clearly, vendors can keep their costs down when they don't have to build their own components or buy licenses for commercial components. Why build a Web server when you can use the best one around-Apache-for nothing? Why build your own OS when you can use FreeBSD? Why not include open-source security utilities with a commercial security product?

While some people automatically assume that open-source OSes are more secure than proprietary OSes, it entirely depends on how the code is used and supported. When done right, open-source components add real value to commercial products-and are likely to be at least as secure as closed-source components.

So what exactly is open-source code, and what impact does it have on product security? How can it affect your systems and networks? How can you tell if the product you're using incorporates open source? And how can you become an intelligent consumer of products that use open source?

... ... ...

Risks and Rewards of Open Source in COTS Products
The common assumption among developers and engineers is that the "many eyes" approach to open-source code projects makes it inherently more reliable, robust and secure than closed-source code. However, recent revelations of glaring holes and vulnerabilities in sometimes quite old and widely used open-source code have led some to question the validity of this assumption. Steve Lipner, manager of the Microsoft Security Response Center, points to the recent discovery of vulnerabilities in MIT's Kerberos network authentication software, "where buffer overruns went undiscovered for nearly a decade" in the widely distributed and implemented open-source code. (Microsoft released a closed-source-and slightly non-standard, and thus non-interoperable-version of Kerberos with its Windows 2000 suite.)

While few open-source advocates still claim absolute security superiority over closed source, most experts seem to agree that open source has the potential to be at least as secure, if not more secure, than closed source. For one thing, open-source code by itself should have no real adverse effect on system security. "The negative ramification that people cite is that - anyone can look at the code to find holes,'" says Bastille's Jon Lasser. But that works both ways, since open-source vulnerabilities are (in theory anyway) vetted by a much larger community of developers and engineers.

"I'm not convinced that there are any significant real advantages to going with closed source unless there is something about the security mechanism itself that intrinsically can't stand up to examination" says Paul Robichaux, a senior solutions architect for EntireNet and author of several books on Microsoft products.

Robichaux stops short of unqualified endorsement of the open-source security model, cautioning that having "more eyeballs looking at [open-source code] is no guarantee of quality." Moreover, for some systems, such as national security programs, close public scrutiny is unwarranted. "If you look at the authentication system…the [U.S.] National Command Authority uses when they want to tell somebody to launch a nuclear missile, you probably would not gain any security from having many more eyeballs looking at that."

Microsoft's Lipner acknowledges that "no software is free from flaw," while suggesting that "the difference between products lies in how actively vendors seek out the flaws and then fix them." According to Lipner, Microsoft "pays top dollar to ensure that its software is scrutinized by the best minds in the industry rather than taking the open-source approach of relying on hobbyists and--someone else' to scan code in their spare time."

Microsoft's official position on the relative security of closed- and open-source software, according to Lipner, is that "the difference lies in how we-do' security. The most fundamental question to ask when examining the security of any software is whether or not the design and development process results in a sound and secure design and a solid implementation." Microsoft isn't opposed to open reviews of cryptographic protocols and algorithms; Lipner says that they "can definitely improve security. These are generally simple enough that academic or external review can find issues and add value."

However, Lipner points out that securing large software systems calls for "a substantial and often costly level of resources applied by a full-time team"--which, he says, will only work if the costs can eventually be recovered by product revenue.

According to Bastille's Lasser, "Anyone using open source can fix the code, or pay someone else to fix it. And anyone can examine it." One result of this all-hands-on-deck model is the potential for discovering backdoors. For instance, Lasser points to the Borland InterBase, initially a proprietary product that, after seven years, was released as open-source code. The proprietary version contained a backdoor that wasn't discovered until six months after the code was opened.

Kurt Seifried, senior analyst for SecurityPortal.com and project head for the Linux Security Knowledge Base, explains that attackers don't need access to the source code to find and exploit problems. For instance, Microsoft issued more than 100 security advisories in 2000, and new bugs related to IIS or IE are publicized on Bugtraq and NTBugtraq all the time.

That's not to say that open-source code has no downside, particularly when implemented in commercial products. It all depends on who is doing the implementation and how support is being provided. Lasser suggests that in order to keep customers' code current, vendors should offer opt-in e-mail lists for up-to-date news about the product, be up-front about any security problems and provide patches online that have been cryptographically signed. While vendors such as Red Hat, SuSE and Mandrake offer these services, "few vendors do all of this," he says.

Seifried, singling out OpenBSD, says some open-source projects are particularly well suited to secure deployment in commercial products. "They sat down and spent a large number of man-years auditing it heavily and now have a pretty solid and secure codebase to work from." Many commercial vendors use OpenBSD--as well as FreeBSD and NetBSD--for firewalls.

However, inappropriately using a secure and open program is dangerous. "It's almost always a question of how the products are used, rather than what they are," Lasser notes. "One of the defining characteristics of the security problem is that these evaluations are fluid, depending largely on new exploits and classes of exploits that are discovered." Just because OpenBSD is noteably secure doesn't mean it's not still vulnerable to common exploits of programs like FTP, DHCP and Send-mail. If someone used OpenBSD as part of a "secure FTP solution," but used an insecure FTP implementation, "they're toast," says Lasser.

Buying Open Source Under the Covers, Intelligently
Vendors incorporate open-source code in their products differently, so simply scrutinizing brochures or Web sites isn't enough. Some vendors make open source an important part of their marketing strategy, pointing to it as a source of strength. Examples include C2Net and Linux-based firewall vendor Cybernet Systems Corp. (www.cybernet.com).

Network security appliance vendors sometimes include lists of software installed on their hardware. Read the fine print in datasheets for Sun's Cobalt RaQ, Qube and other network appliances (www.sun.com), and you'll see that those products use the Linux 2.2 kernel. Axent's (now Symantec's) Raptor firewall appliance (www.symantec.com) is also based on the Cobalt RaQ. Other vendors are less forthcoming, releasing appliances based on "proprietary" OSes that are, in fact, open-source based. For example, the FireBox network appliance from NetWolves (www.netwolves.com) is based on FreeBSD-but the company's Web site refers to it as a "Unix-based FoxOS" operating system.

The greatest benefit of buying products that incorporate open source can also be part of the greatest drawback--that is, the fact that vulnerabilities and exploits for leading open-source products are widely published. This means fixes are usually made available quickly, but it also means that if you take too long to update your systems, they will be vulnerable to script-kiddiez and other attackers.

Bastille's Lasser suggests that vendors should provide proactive support, notifying customers of vulnerabilities and fixes. However, in his opinion, knowing where a particular piece of a system originated, whether open source or not, is not always very useful. "Sure, you could ask whose TCP/IP stack they used, but you won't know which version, and the optimal solution varies by week, application and phase of the moon," Lasser opines. But he also acknowledges that "there's nothing especially specific to open source about any of this."

In the final analysis, it's up to consumers to keep track of what open-source code is running on their systems--if only to keep them up to date. SecurityPortal's Seifried suggests asking vendors for a list of their product's security patches. "If they don't have any patches, I wouldn't buy it. Nothing is perfect.

"Open source is like any technology," he adds. "The implementation can be good or bad. Vendors that use open source and issue timely updates, proactively audit code and so on are good; vendors that don't should be avoided if possible."

Could You Do It Yourself?
Vendors use open-source code to build their products, so why can't anyone else? Well, nothing's stopping them, but the question is whether they can afford to (see box, below). A vendor can afford to put significant resources into putting together a package from open sources as long as they anticipate revenues. Seifried says it's a matter of convenience. "I can easily download the Linux kernel source and all the source code for software I need. Turning that into a working e-mail server, on the other hand, is a completely different matter."

According to Lasser, there are three other good reasons not to "roll your own." First, commercial versions of open-source programs usually incorporate proprietary extensions that add significant value. For example, C2Net's Stronghold Web server adds strong encryption and other features to Apache. Also, with proprietary products you get the benefit of quality assurance. And finally, you get support. "You're not paying for the software so much as you are to have someone to complain to when things break," Lasser says.

Buying commercial products based on open-source components may give users the best of both worlds. Microsoft's Lipner suggests that "proprietary systems are better reviewed, better tested and have a more robust process for dealing with security vulnerabilities when they are found"-though he was thinking more of entirely proprietary systems like those available from Microsoft. Everyone seems to agree that a proprietary product provides greater ease of use, better support, more convenience and more features, whether or not the proprietary product incorporates open-source code.

OPEN SOURCE INSIDE

Download pdf

BACKDOORS: OPEN OR CLOSED?

Backdoors are the security manager's nightmare. About the worst thing that could happen from a security standpoint would be the deployment of a system that includes an unknown backdoor.

The fear of backdoors "has probably been the biggest drag on the adoption of open source in the commercial world," says security expert and author Paul Robichaux. He recommends taking great care in reviewing any code brought in-house. "If you're using open-source code and you're not already reviewing it very carefully, you're being stupid and you deserve what you get," he says.

In the open-source world, it's likely that any externally injected malware (such as a Trojan) will be caught before it can be incorporated into production systems. But Robichaux warns that when you are buying compiled products (such as security appliances)--whether open source or not--"you never know what's going to be in those."

Rumors of backdoors inserted into commercial products have persisted for years. According to Robichaux, it's plausible (though never confirmed) that government agencies such as the National Security Agency (NSA) could "go to Microsoft or Sun or Oracle or whoever and wave their magic national security wand." As a result, "The product you're using will have a hole in it, but you won't necessarily find out."

Those using open-source code-whether it's the native code itself or a COTS product based on it-face a Catch-22 when it comes to backdoors. On the one hand, attackers are more likely to try to insert a backdoor into open-source code because, unlike closed source, it's out in the public domain for everyone to play with. On the other hand, they will be less likely to succeed because there are so many other people, with different goals, looking at the same code, which increases the possibility that it will be noticed.

BUILDING YOUR OWN FIREWALL

Time is money, and it's well worth spending a few thousand dollars to save a few weeks of a security manager's time.

When the Internet was still a research network, it was built on BSD/Unix systems. BSD derivatives, like all Unix flavors, are designed from the ground up to run on networked devices. So it shouldn't surprise anyone that so many firewalls and Internet servers are based on BSD-related distributions. Linux, with its relatively easy-to-use firewalling and Network Address Translation (NAT) functions, is also a popular platform for security applications.

If you have Linux, BSD or Unix expertise--or at least plenty of time--BSD- and Linux-based firewalls can be cheap and effective security solutions. But doing it yourself can be an invitation to disaster unless you're sure you've done everything right.

Once you decide to build your own firewall, you must install the operating system as securely as possible, and then create firewall rules to keep out all unauthorized traffic. That means building security policies first--a prerequisite for any firewall.

First, you must choose the most appropriate OS. Some prefer Linux for ease of use and widespread support; others find one of the BSD flavors (OpenBSD, NetBSD, FreeBSD, etc.) stronger (though perhaps less user friendly). If you choose Linux, you now have the option of using the 2.2 kernel, which provides firewall support with packet filtering by the ipchains program; or the 2.4 kernel, which uses the iptables program to create stateful inspection firewalls.

The next step is to get a trustworthy distribution: that means downloading from a trusted Web site or buying it on CD-ROM-and checking the distribution's digital signature. You'll want to review the source code before compiling it, and you should compile the kernel with only the drivers that are absolutely necessary.

Once installed, you'll need to turn off all extraneous services and harden the operating system in other ways (see Resources). You can do it by hand, or use a Linux-hardener (for example, the Bastille hardening scripts). Then, you've got to develop your firewall rules: what kind of packets should be filtered-both inbound and outbound-what applications are permitted, and so on.

Building and configuring the box, of course, is only the first step. Once the firewall is in operation, you must constantly monitor logs for suspicious activities, watch out for security alerts and install security patches as soon as they are available.

Some of these tasks (setting firewall rules and staying on top of security alerts, for example) are necessary with any firewall. But if you roll your own, you don't have the option of outsourcing any of them to a commercial firewall vendor.

RESOURCES

Download pdf