Security — Open Vs. Closed
AlexGr points out an article in ACM Queue, "Open vs. Closed," in which Richard Ford prods at all the unknowns and grey areas in the question: is the open source or the closed source model more secure? While Ford notes that "there is no better way to start an argument among a group of developers than proclaiming Operating System A to be 'more secure' than Operating System B," he goes on to provide a nuanced and intelligent discussion on the subject, which includes guidelines as to where the use of "security through obscurity" may be appropriate.
I wonder which side slashdot will take in this argument...
Applications and systems developed that are developed rapidly by a small set of programmers would benifit from closed source security especially when producing software for small niches. Systems that are developed on a large scale and mission critial applications benefit from open source models because that can utilize a large tester base.
Vista Forum
Windows Vista Help Forum
Businesses that choose to develop closed-source software seem to also choose to ship code prematurely, to over-provision with extra features, to decide on features for marketing rather than security or quality reasons, and generally compromise the product in multiple ways. In that light, closed source isn't itself the security problem, it's just an indicator that there probably are other problems lurking.
The Operating System most secure is the Operating System less used.
With regards to the question which product is more secure, the only right answer is that you will never know. The problem is that you can't eliminate bias from a test that is supposed to assess this. Since a single product can't be both open source and closed source, you will always be comparing multiple products. As stated earlier, you can't reliably establish the relative security of these products, let alone attribute the result to open vs. closed source.
Please correct me if I got my facts wrong.
One supposed advantage of open source software is that, well, it's open. Everybody can take a look and see if the code has holes. The idea being that the more eyes that look at something, the greater a chance of somebody seeing bugs.
But the quantity of eyes isn't always the issue. I could put the Linux kernel source code in front of 1 million six year olds, and there is very little chance any of them would find a single bug.
Obviously, we're not talking about six year old eyes here, but continue the scenario. There are some types of bugs that even very experienced coders wouldn't necessarily spot. Not every kind of security hole is a simple buffer overflow. Some kinds of issues will really only be spotted by a highly trained and specialized set of eyes.
Now, those highly trained eyes may be looking at the open source code, or they may not. All I'm saying is that the quote "Given enough eyeballs, all bugs are shallow" is not particularly accurate.
While Ford notes that "there is no better way to start an argument among a group of developers than proclaiming Operating System A to be 'more secure' than Operating System B,"
;-)
Unless of course Operating System A is Open BSD
This debate is all about the incorrect question. The reason is that code can be secure or not secure, regardless of its "open" or "closed" status.
Until the industry realizes that "secure is secure" and stops worrying about the open or proprietary nature of things, this debate will probably prevent things from being as secure as they could be by diverting resources to an analysis rather than any solutions.
Put another way: Is a homemade door more or less secure than a professionally installed door? My answer is "it depends on the skills of those involved and the quality of materials".
The same applies to software.
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
Is always a good first line of defense. At least it keeps out the riff-raff. Until someone smarter writes the scripts for them.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Closed security: the Titanic is unsinkable - White Star line
Open security: the Titanic's hull is made of brittle metal and thus isn't safe - Independent safety inspector
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
The same old argument for openness applies to open source. You have to assume the black hats will find and try to exploit vulnerabilities. Without that assumption, there isn't much to worry about. But given that the black hats will find vulnerabilities and use them, the best thing we can do is to make sure the white hats find the vulnerabilities, too. This way, the vulnerabilities can be fixed or worked around (e.g. through firewalls). The vulnerabilities exist whether or not you know about them, but, if you know about them, you can take adequate measures. Open source makes it easier to find vulnerabilities, and thus, to know about vulnerabilities.
Of course, open source also makes it easier for the black hats to find the vulnerabilities. So there's an arms race here. If the black hats find the vulnerability first, they can exploit it before it gets patched or worked around. If the white hats find it first, it can be fixed or worked around before it is exploited. The same arms race exists for closed source and open source, but, in the case of closed source software, the developers are (supposedly) the only ones with the source code, which gives them a slight edge in the arms race.
So it seems that both open source and closed source have advantages and disadvantages when it comes to security. Furthermore, I think that both arguments are theoretical, and the advantages that both models have are not always exploited. Having the source available does not help if no white hats are actually auditing it. And this is why open source wins, in my book. With open source, if you're concerned about vulnerabilities in the software and don't trust the rest of the world to have done proper audits and notified you about the results, you can do your own audit. If the developers of the software don't fix the vulnerabilities to your satisfaction, you can do so yourself. With closed source, you are at the mercy of the vendor. If they don't do proper audits, you're out of luck. If they don't fix vulnerabilities, you're out of luck.
Proprietary software vendors do not always have your best interests in mind. It's not unusual for vendors to keep silent about vulnerabilities found and/or fixed in their software, and some vendors have even threatened or sued people who have disclosed vulnerabilities in the vendor's software. The reputation is more important than the _actual_ security of the product, because the actual security is unknowable. With open source, such tacticts don't work. The source is out there, anyone can find the vulnerabilties and assess the security for themselves. If things are fixed, anyone can make a diff between the two versions and see what was fixed. They can't keep the information from you. Your security benefits from that.
Please correct me if I got my facts wrong.
Personally, I would argue that such 'heuristically secured' systems are broken by default, and that there are good reasons why generations of computer scientists have insisted that security through obscurity is meaningless. The "security" provided by such heuristics are of value only to marketing and legal departments, they are not and should not be confused with the security offered by 'deterministically secured' systems (e.g. cryptography is his example). Saying that an application is "secure," when it depends on an attacker not knowing how it works, borders on unethical false advertising.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
And on servers I run like that, I have yet to have a breakin, but I do get up to thousands of connection attempts from ssh worms, from the same servers, every day (well, they would if I stopped dropping them in iptables, but nevermind that). So it's possible that they could hit a user with a bad password, or one they got from another compromised machine.
On other boxes, like my home box, I put SSH on a high-numbered port. In a couple of years I've had zero attempts hit that port. It would be quite stupid to rely only on this trick, ignoring good discipline in other areas. But as a supplementary layer, it's quite useful. If nothing else, it saves bandwidth.
It's not sufficient, but it's not inherently bad.
This is slightly off-topic, but a while back I got interested in OpenVMS, and VAX stuff in general. (I started doing some research because I thought I was going to get stuck doing some turd polishing of old mainframe software, but it never materialized. But by then I was just interested.) Even in hindsight (given that I think we can agree that UNIX-derivatives seem to have gained traction over VMS), it's extremely difficult to find any sort of rational comparisons of VAX/VMS and its architecture and design paradigms to that of UNIX. Whenever someone asks, the response is basically "don't ask, you don't want to start that." Nobody wants to talk about anything that might invite UNIX/VMS comparisons, because it will cause flamewars -- even though such a discussion, at this point, might be interesting and productive. (There are so many people around who aren't familiar with VMS, or anything other than Windows and UNIX, that any perspective besides those would be worthwhile.)
At any rate, it struck me as interesting, because sometimes it's easy to assume that Windows/Linux (or Windows/Mac, or Windows/something) is the first Great OS War. But people have been getting emotionally attached to operating systems, probably as long as they have existed; and ever since, it has helped quash rational discussion, both through flamewars themselves, but also because of self-censorship that occurs, in order to try and prevent arguments.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Closed doesn't mean nobody has seen it. MS for example gives it source code to many 3rd parties for review and analysis. If source code is subject to extensive 3rd party review, closing it to the general public adds an additional layer of security. Security through Obsurity may not be a great stand alone security model, but as part of security indepth it can be. It should be used as one of many layers.
Closed-source, then, offers no meaningful protection to the companies involved. Precisely because they have no objection to stealing from competitors, corporations who rely on trade secrets and security through obscurity invalidate the very model they are based upon. If you work on the basis of all people being corruptible, you cannot also work on the basis of people not being corruptible. If you abuse the trust of others, you will inevitably be subjct to the abuse of trust.
Open source doesn't guarantee that the eyes looking at the code are of any particular quality, or that they'll give information back, or that they won't steal the code anyway. But at least you know the possibilities and accept them, you don't pretend they don't exist.
In the end, the difference between the two models is that one deludes the managers into believing they have something nobody else has. Open Source has its own delusions - that the developers can do a damn thing if a corporation takes the code, patents it, and sues said developers into oblivion, for example. One could argue that both are virtually unsurvivable disasters and that you might as well go for the one that gets you the money and the groupies. On the other hand, the reality is that programmers don't make money (managers do) and the last geek known to have had groupies was Socrates.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
If you can't prove it is secure by showing me how it works, then it's not secure. How do I know that there isn't some bolt in the back of the bank vault, or some skeleton key, unless you allow me to inspect it myself?
Security by faith or by fact, which would you prefer?
stuff |
In my experience there is no big difference between the security of closed and open software.
1) Even if the source code is available for people to check, if nobody else bothers checking but the author there's no difference right?
2) It's the quality of the checking not the quantity. A billion stupid monkeys won't know the difference between good code or bad code.
What you should do is see who made the stuff and what their track record is like.
I can confidently say Firefox will continue to have regular security bugs for years, and that any claims that it is far more secure than IE are hype. The fact that it is written in an unsafe language and crashes regularly means it has both code quality issues and security issues. Don't even need to look at the source to tell.
It seems as if that there are fewer than 10 people in the world who know how to code safely in C (or C++) AND actually do it.
I'm definitely not one of them.
I think you've introduced a new concept here - security through incomprehensibility.