Managing Network Security
Is Open Source More or Less Secure?
by Fred Cohen
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.
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.
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
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
- (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
- (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
- (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
- (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
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
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.
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/