- Email: [email protected]
Is Open Source More or Less Secure?
nesejulymayfield.qxd
7/25/02
3:53 PM
Page 17
managing network security
Is Open Source More or Less Secure?
(pro open) We can do systematic analysis of the code with automation to find bugs. (pro closed) Hackers 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'.
Fred Cohen Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection programme 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.
(pro closed) We can patch it properly instead of creating more holes along the way.
meet their desire to win 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, I thought I might start down this road in this article because I was not funded to do it. 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, its tough luck for you and in this case I would want payment in advance.
(pro closed) The vulnerability will not be spread around as fast without the source being released.
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 and 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 details 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
Parameters The basic positions of the two sides in this debate come down to: (pro open) More eyes on the code make it more likely that the bugs will be unearthed. (pro closed) If hackers 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 find work-arounds while waiting for real patches to be completed.
(pro open) We can better secure against changes and Trojans when the code is publicly available. (pro closed) We can better secure against changes and Trojans when the source code is proprietary. (pro open) We despise proprietary vendors because you make us pay you for using your programs (pro closed) We despise open-source because you are taking away our hard-fought revenues . In my usual fashion, I will now focus on each of these ideas one by one. Don't count on any of them still standing at the end.
Counterpositions (pro open) More eyes on the code make it more likely that the bugs will be unearthed: This is pure nonsense. It's not quantity but quality that counts and professionals that are paid to do the job well and properly funded with tools and facilities can do this far better than amateurs doing it in their spare time for fun. On
17
nesejulymayfield.qxd
7/25/02
3:53 PM
Page 18
managing network security 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 people who evaluate open source software 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 them and follow their advice, we would have far fewer flaws in closed source software as well. (pro closed) If hackers can see the code they are more likely to find exploits: This is pure nonsense as well. In fact, more exploits have been found and exploited in closed source code 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 discovered 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 people 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 discover lots of bugs and many of them remain unfixed. By way of example, there is an interesting paper in
18
the 2002 IEEE Oakland conference where a groups of students found more than 1000 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) Hackers 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 properly 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 people who make 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 being released:
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 the code is available to everyone: This is not at all clear. Just because it is open source does not make the archives more secure. Indeed more people 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. Indeed one major vendor has 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 a certain vendor has done, and more than one closed source vendor is subject to similar problems. (pro open) We despise proprietary vendors because you make us pay to use 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 despise open source because you are taking away our hardfought 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
nesejulymayfield.qxd
7/25/02
3:53 PM
Page 19
managing network security 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 proprietary products? Sure — when there is something that I can only do with a proprietary operating system. 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 advocates 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 dispel the rumors and get down to specific 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 overthe-Internet as a practitioner in residence in the University of New Haven's Forensic Sciences Program. He can be reached by sending email to [email protected] or visiting http://all.net/
event CSI NetSec, 2002, San Francisco The Computer Security Institute’s 12th annual NetSec 2002 event in San Francisco had a sobering edge to it. Although it was apparent that security vendors were present with the appropriate products it was noticeably free of commercial hype and virus scares. This suggested that the event was obviously for those ‘in the know’ about network security. The attendees seemed to be experienced security professionals, the type who automatically know that the latest frilly virus will not touch their networks because it has not reached the ‘wild’. A selection of tracks at the event focussed on wireless security, forensics, IDS and E-commerce security among others. In a presentation by Bruce Schneier, he used the analogy of the police and emergency services to describe a network attack. He said that monitoring a network in reality means six weeks of boredom and eight days of panic. Human experts are needed to decipher if a real attack is happening but only occasional expertise is needed. Technology assists people only and 24X 7 vigilance is necessary. Schneier believes that network monitoring may eventually be outsourced. PDA security was covered in a presentation by Rebecca Herold from QinetiQ Trusted Information Management. According to Gartner, the biggest threat to a PDA is losing it or having it stolen, an estimate in January 2002 predicts that 250 000 PDAs will be lost at airports alone in 2002. Password usage and file importing are also viable risks. Herold points out that
it is important to know what workrelated information employees are storing on their PDAs. Herold recommends that “organizations must establish policies, regulations and standards for PDA users”. Examples of policies to be implemented include selecting certain applications that can’t be used on PDAs and immediately locking out lost or stolen PDA devices from network access. Fred Avolio delivered a presentation on wireless security. He began by declaring how wireless is cheap and easy. “But security and cheap and easy solutions do not always go together” he said. Wireless networks transmit on a ‘no license required frequency’, so anyone with a scanner can scan open radio frequencies. With wired networks phyical access to the network is necessary, with wireless this is not the case. Avolio categorized the main threats to wireless networks into “attackers and squatters”. Attackers are hackers who want to steal information, an example would be a competitor. Squatters are hackers that desire a free bandwidth ride, their motivation is to get access to the Internet. Avolio also discussed how Wired Equivalent Privacy, (WEP) was the intended solution to wireless security but because this was designed by “network people rather than security people”, it is full of weaknesses. He indicates that working around wireless security to make it safer is a “synergistic” effort involving simple steps that do not fully alleviate the problem but do decrease the risk.
19
7/25/02
3:53 PM
Page 17
managing network security
Is Open Source More or Less Secure?
(pro open) We can do systematic analysis of the code with automation to find bugs. (pro closed) Hackers 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'.
Fred Cohen Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection programme 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.
(pro closed) We can patch it properly instead of creating more holes along the way.
meet their desire to win 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, I thought I might start down this road in this article because I was not funded to do it. 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, its tough luck for you and in this case I would want payment in advance.
(pro closed) The vulnerability will not be spread around as fast without the source being released.
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 and 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 details 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
Parameters The basic positions of the two sides in this debate come down to: (pro open) More eyes on the code make it more likely that the bugs will be unearthed. (pro closed) If hackers 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 find work-arounds while waiting for real patches to be completed.
(pro open) We can better secure against changes and Trojans when the code is publicly available. (pro closed) We can better secure against changes and Trojans when the source code is proprietary. (pro open) We despise proprietary vendors because you make us pay you for using your programs (pro closed) We despise open-source because you are taking away our hard-fought revenues . In my usual fashion, I will now focus on each of these ideas one by one. Don't count on any of them still standing at the end.
Counterpositions (pro open) More eyes on the code make it more likely that the bugs will be unearthed: This is pure nonsense. It's not quantity but quality that counts and professionals that are paid to do the job well and properly funded with tools and facilities can do this far better than amateurs doing it in their spare time for fun. On
17
nesejulymayfield.qxd
7/25/02
3:53 PM
Page 18
managing network security 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 people who evaluate open source software 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 them and follow their advice, we would have far fewer flaws in closed source software as well. (pro closed) If hackers can see the code they are more likely to find exploits: This is pure nonsense as well. In fact, more exploits have been found and exploited in closed source code 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 discovered 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 people 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 discover lots of bugs and many of them remain unfixed. By way of example, there is an interesting paper in
18
the 2002 IEEE Oakland conference where a groups of students found more than 1000 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) Hackers 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 properly 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 people who make 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 being released:
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 the code is available to everyone: This is not at all clear. Just because it is open source does not make the archives more secure. Indeed more people 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. Indeed one major vendor has 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 a certain vendor has done, and more than one closed source vendor is subject to similar problems. (pro open) We despise proprietary vendors because you make us pay to use 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 despise open source because you are taking away our hardfought 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
nesejulymayfield.qxd
7/25/02
3:53 PM
Page 19
managing network security 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 proprietary products? Sure — when there is something that I can only do with a proprietary operating system. 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 advocates 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 dispel the rumors and get down to specific 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 overthe-Internet as a practitioner in residence in the University of New Haven's Forensic Sciences Program. He can be reached by sending email to [email protected] or visiting http://all.net/
event CSI NetSec, 2002, San Francisco The Computer Security Institute’s 12th annual NetSec 2002 event in San Francisco had a sobering edge to it. Although it was apparent that security vendors were present with the appropriate products it was noticeably free of commercial hype and virus scares. This suggested that the event was obviously for those ‘in the know’ about network security. The attendees seemed to be experienced security professionals, the type who automatically know that the latest frilly virus will not touch their networks because it has not reached the ‘wild’. A selection of tracks at the event focussed on wireless security, forensics, IDS and E-commerce security among others. In a presentation by Bruce Schneier, he used the analogy of the police and emergency services to describe a network attack. He said that monitoring a network in reality means six weeks of boredom and eight days of panic. Human experts are needed to decipher if a real attack is happening but only occasional expertise is needed. Technology assists people only and 24X 7 vigilance is necessary. Schneier believes that network monitoring may eventually be outsourced. PDA security was covered in a presentation by Rebecca Herold from QinetiQ Trusted Information Management. According to Gartner, the biggest threat to a PDA is losing it or having it stolen, an estimate in January 2002 predicts that 250 000 PDAs will be lost at airports alone in 2002. Password usage and file importing are also viable risks. Herold points out that
it is important to know what workrelated information employees are storing on their PDAs. Herold recommends that “organizations must establish policies, regulations and standards for PDA users”. Examples of policies to be implemented include selecting certain applications that can’t be used on PDAs and immediately locking out lost or stolen PDA devices from network access. Fred Avolio delivered a presentation on wireless security. He began by declaring how wireless is cheap and easy. “But security and cheap and easy solutions do not always go together” he said. Wireless networks transmit on a ‘no license required frequency’, so anyone with a scanner can scan open radio frequencies. With wired networks phyical access to the network is necessary, with wireless this is not the case. Avolio categorized the main threats to wireless networks into “attackers and squatters”. Attackers are hackers who want to steal information, an example would be a competitor. Squatters are hackers that desire a free bandwidth ride, their motivation is to get access to the Internet. Avolio also discussed how Wired Equivalent Privacy, (WEP) was the intended solution to wireless security but because this was designed by “network people rather than security people”, it is full of weaknesses. He indicates that working around wireless security to make it safer is a “synergistic” effort involving simple steps that do not fully alleviate the problem but do decrease the risk.
19