Series Introduction

Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection program success depends more on prudent management decisions than on the selection of technical safeguards. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.

No.

Now that you know the conclusion of this month's article - that open source is not, more or less, secure, you might want to know that closed source software is also not, more or less, secure, Most software today is really far less secure than those of us who want effective protection would have it. That goes for open and closed source. But the question of which we should use under what circumstances remains an issue that we should address for our organizations and ourselves.

By way of full disclosure, I should note that I both buy and sell closed, slightly open (open to customers only), and open source software. So I obviously think that each is a viable approach depending on the specifics of the situation. The question then remains of how the balance of factors influences decisions in this regard.

Metrics

First and foremost, in comparing open source to closed source, we need some basis for comparison. Since there are no applicable security metrics suited to this question, at least as far as I am aware, we probably need to create some if we are to have a basis for a meaningful comparison.

In order to create such metrics we probably need to start with some notion of the parameter space. And here we run into further problems because those in the 'debate' each seem to select their parameters to meet their desire to won the debate rather than to help us make better decisions. Naturally nobody will fund a 'neutral' study in this regard and whoever did fund it would be scrutinized for it and the results would be scrutinized based on the funding source. Since nobody in this industry is beyond reproach (present company excepted) I thought I might start down this road in this article because I was not funded to do it and because Network Security Management's level of payment for these articles wouldn't influence a starving man to eat a slice of bread. (Editors - please note the not-too-subtle hint at a pay raise).

Of course you get what you pay for, so this is not the result of some extensive study or deep analysis. If you want to fund me to take up your side, I am generally available at my normal fees, but be warned, my contracts stipulate that if you don't like the results, it's tough luck for you - and in this case I would want payment in advance.

Parameters

The basic positions of the two sides in this debate come down to:

• (pro open) More eyes on the code makes it more likely to find the bugs
• (pro closed) If bad guys can see the code they are more likely to find exploits
• (pro open) Closed source can be decompiled and the code exploited anyway
• (pro closed) Seeing the source makes it a lot easier to exploit or corrupt
• (pro open) We can do systematic analysis of the code with automation to seek out bugs
• (pro closed) Bad folks cannot do systematic analysis of code to seek out bugs
• (pro open) We can change it as needed to fix the holes without waiting for a 'patch'
• (pro closed) We can patch it right instead of creating more holes along the way
• (pro open) We can find work-arounds while waiting for real patches to be completed
• (pro closed) The vulnerability will not be spread around as fast without the source out there
• (pro open) We can better secure against changes and Trojans when all have the code
• (pro closed) We can better secure against changes and Trojans when the source code is proprietary
• (pro open) We hate you folks because you make us pay you for using your programs
• (pro closed) We hate you folks because you are taking away our hard-fought revenues

In my usual fashion, I will now rip into these positions one at a time. Don't count on any of them still standing at the end.

Counterpositions

• (pro open) More eyes on the code makes it more likely to find the bugs: This is pure baloney. It's not quantity but quality that counts and professionals paid to do the job well and properly funded with tools and facilities can do this far better than ametures doing it in their spare time for fun. On the other hand, most closed source companies do not actually pay qualified professionals to do this sort of job or provide those who do the job with adequate funding or other resources. Many of the folks who evaluate open source are professionals who have a desire to do this sort of work but don't get paid for it - so they do it for the good of all. If closed source companies would hire tham and follow thier advice, we would have far fewer flaws in closed source software as well.
• (pro closed) If bad guys can see the code they are more likely to find exploits: This is pure baloney as well. In fact, more exploits have been found and exploited in closed source code by bad guys than in open source code. But this may be greatly influenced by the fact that more of the closed source code is more widely embedded in the market (although that is changing as is the overall statistic). Indeed more bugs are published associated with open source code, but these bugs are also patched as they are found so that the net effect is less exploitation.
• (pro open) Closed source can be decompiled and the code exploited anyway: True - but 'can be' and 'is' may be two different things. In truth it is easier to exploit code given the source because it is (usually) easier to read and understand by people and computer programs when it is in a higher level of abstraction.
• (pro closed) Seeing the source makes it a lot easier to exploit or corrupt: True - but if lots of folks see it the odds of it remaining corrupt may go down, and of course seeing it makes individualization easier and more likely which may lead to fewer systemic common mode failures.
• (pro open) We can do systematic analysis of the code with automation to seek out bugs: Sure you can, but this is really only done today by university students seeking MS degrees. They find lots of bugs and many of them remain unfixed. By way of example, there is an interesting paper in the 2002 IEEE Oakland conference where a groups of students found more than 1,000 faults in Linux modules that could be exploited. Only a small portion of them were fixed by the time of publication. Many fewer were detected in FreeBSD and they were fixed immediately.
• (pro closed) Bad folks cannot do systematic analysis of code to seek out bugs: Of course they can, but apparently they don't have to. There seem to be so many bugs in popular closed source code that they are rapidly found without access to the source code. And of course the source code often leaks out anyway - even (especially) with the biggest of the vendors. If they can't even protect the source code they call closed source from exposure, how can they claim they are able to protect us when using it?
• (pro open) We can change it as needed to fix the holes without waiting for a 'patch': This is true, and in many cases, open source patches are found and promulgated within a few hours of identification of a vulnerability. In general, open source software in widespread use is patched very quickly.
• (pro closed) We can patch it right instead of creating more holes along the way: This is not true. There is no reason to believe that closed source patches are better than open source ones, and there is a long history of closed and open source patches introducing further vulnerabilities.
• (pro open) We can find work-arounds while waiting for real patches to be completed: True but largely irrelevant. Unless you are one of those folks who makes instant personal patches to every piece of code as soon as every error is detected, this is not important to you. And of course there is usually the work around of temporarily disabling a service while awaiting the patch.
• (pro closed) The vulnerability will not be spread around as fast without the source out there: This is not supported by history. We have lots of cases of viruses spreading around the world in hours by exploiting closed source vulnerabilities (as well as open source ones). Closed source seems to have nothing to do with this.
• (pro open) We can better secure against changes and Trojans when all have the code: This is not at all clear. Just because it is open source does not make the archives more secure. Indeed more folks have access to the source and anyone can become a distributor and add Trojans along the way. This has been done on many occasions.
• (pro closed) We can better secure against changes and Trojans when the source code is proprietary: This is clearly not true. There is no real reason to believe that closed source is more secure from Trojans, and indeed, Microsoft has had so many major Trojans in their software that they decided to call them Easter Eggs and promote them as fun. No open source program could ever get away with a Trojan flight simulator in a word processor like Microsoft has done, and other closed source vendors are also subject to similar problems.
• (pro open) We hate you folks because you make us pay you for using your programs: Get a grip. If they want to charge, you can vote with your pocket book (unless their monopoly prevents you from doing so, in which case you can sue them).
• (pro closed) We hate you folks because you are taking away our hard-fought revenues: Life is tough. If you want to retain your revenue stream, try putting out better quality products and serving your customers better.

How do I decide?

That's easy. I only use closed source when it is easier or more cost effective for me (easy being a dominant cost factor for most software in my case). I only choose open source when it is easier or more cost effective for me as well. All things otherwise being equal, I will choose open source on the off chance that I would one day decide it was worth looking at the code for some reason or another.

Do I buy Microsoft products? Sure - when there is something that I can only do under Windows. Would I rather use open source? Sure - I use Star office except when I absolutely must use word because of an intentional incompatibility they created, but nothing touches Microsoft Project for the cost today.

Do I sell Microsoft? No way. All of my products start with open source and augment them (added value I guess I should call it) with open or closed source as appropriate. I too like to protect my investment of time and effort by keeping some of my source code proprietary. Can someone malicious decode it? Sure, but I want to make it harder.

Conclusions

Well, now I've done it again. I've wasted another 24 column inches and 15 minutes of your valuable space and time while offending everyone on all sides of this issue. When will I learn? Probably the same day that the open source and closed source folks agree on their positions. We will all be long dead by then.

Is there a conclusion to be drawn? Sure. Open and closed source each have their places and you need to put them and keep them in their places.

My method of deciding on open vs. closed source is ad hoc and perhaps unworkable for a major corporation such as yours, but I am sure that you will be able to find your own way to go about it - now that you have the facts to dispell the rumors and get down to cases.

About The Author:

Fred Cohen is researching information protection as a Principal Member of Technical Staff at Sandia National Laboratories, helping clients meet their information protection needs as the Managing Director of Fred Cohen and Associates, and educating cyber defenders over-the-Internet as a practitioner in residence in the University of New Haven's Forensic Sciences Program. He can be reached by sending email to fred at all.net or visiting http://all.net/