Slashdot Mirror
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.
http://www.acmqueue.com/modules.php?name=Content&p a=printer_friendly&pid=453&page=2
Cleverly hidden on page 2 of 4 advertisement-riddled pages. You would think ACM could focus on the content with less distractions than other sites...guess not.
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
FTFA - For example, passwords are the perfect example of "acceptable" security through obscurity: they are useful only if the attacker doesn't know them.
I would have thought that the password authentication method was the part that needed to be secured.
Just look at how many times an auth method has been exploited to bypass passwords entirely.
[Fuck Beta]
o0t!
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
Open to the point of letting people know one's password?
.. it should be as "closed" as possible. From good guys, it should be as "open as possible". Because the good guys are likely to tell you flaws in the system, whereas bad guys aren't.
I don't think that works.
Algorithm? May be.
It comes down to this, from bad guys
As a symptom of society in general to become more and more suspicious of each other, what is getting adopted is the worst of both the closed and open model is the one that persecutes security researchers (good guys) for finding vulnerabilities. Furthermore, it is fast becoming a crime to warn your friends that a particular software may be easily compromisable.
Reverse engineering must be legal. Warning people of vulnerabilities must be legal.
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.
Which, regardless of operating system, is the interface unit located between the chair and keyboard. That interface can bring the most secure system to its knees.
The author already mentioned MS-DOS. See his comments, which refute your point.
"it might be possible to conclude that MS-DOS with a TCP/IP stack is more secure than a fully patched Windows XP box..."
Please show me one real security professional who would suggest using MS-DOS for a system which
had to be secure.
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."
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 real issue is whether the house to which that door allows access is more secure if you publish its plans or not.
That is hard to answer, because you don't know if the homeowner is relying on the secrecy for security, or just wants to sell house plans. If the homeowner thinks his house is safer because no one can open his door without the plans, then he is trusting in security through obscurity.
An inherent flaw in these physical analogies is that they subconsciously tie us to the physical properties of the analogs. Who wants to be replacing doors all the time? I'd rather build it once and not tell anyone how many shims I had to use. But software is generally easier to fix than is a door, relative to their environments, or it should be.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
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."
It's easy to find a buffer overflow by looking for strcpy calls with a debugger in a closed source program. It's a lot harder to fix them in a closed source program though, as you have no idea what to fix. The attacker doesn't need to understand the program to attack it, he just needs to understand a small part of it. The defender needs to understand all of it to patch it. Look at the CTSS bug involving a race condition and the system editor. The attacker just waited, and then he got the password file. Finding out what had happened was a lot harder.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
That was very insightful. Thanks!
Please correct me if I got my facts wrong.
Why is it that people are debating closed versus open software?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Your sig can be simplified to:
:)
ruby -e "[1383424633,543781664,1718971914].each{|x| print([x].pack('N'))}"
I agree with the output though
If you have a large project that only the developers and the bad guys bother to examine closely, it's LESS secure than a similar project with many white-hat eyeballs on it and LESS secure than a similar project with only the developers looking at it.
This assumes the code has security-related bugs that are exploitable if found by the bad guys. It also assumes that the development team, despite their best efforts, doesn't find all the bugs that the bad guys could find if they had access to the source code.
Without the source code, the bad guys can find and exploit bugs, but their job is a lot harder.
Here's an example of how this might come into play in the real world:
I develop a set of cgi scripts to support e-Commerce. I publish them as open-source. They don't get very popular and I'm pretty much the only one using them. A well-known company uses the scripts and some black hats recognize my scripts. They study the source code, find an exploit, and harm the company that's using my scripts.
If the scripts were kept closed-source OR they'd become popular enough to have widespread community bug-squashing, the risk to the end-user would be much less.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Your sig can be simplified to:
ruby -e "[1383424633,543781664,1718971914].each{|x| print([x].pack('N'))}"
You must be using some definition of 'simplified' I wasn't previously aware of.
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)
The article concludes that "Software Engineering is a young discipline". The term was first coined in 1961, so I'd like to suggest that only recently have many agreed on what software engineering actually is, and how it should be undertaken.
Yes. Not only is the wrong question, it doesn't even make sense.
Open source and closed source are methods, security is a result. Security is an attribute of a product, not of a development technique. A closed-source company can assign a hundred reviewers and get more trained eyeballs on their code than most open source projects ever see.
If you want to measure results, there's so much scatter from other causes that any effects of open vs. closed are swamped in the noise. Which would you pick as an example of open source security -- OpenBSD, or sendmail? Which would you pick as an example of closed source security -- VMS, or Internet Explorer?
If you've made all your other security-related decisions and then decide whether to publish source code, one thing to consider is how motivated the attackers are. The crypto community is wedded to published algorithms because they have to face attackers with national budgets who can hire people like Alan Turing. Vertical market software for running the environmental controls in a chicken coop doesn't need, and won't get, worldwide peer review.
There's also the design-to-failure argument. Secrecy is fragile and temporary, and repairs are difficult when it's lost.
Simplify: to make simpler or reduce in complexity.
It's simpler than the original, mr. smarty-pants.
Anyway, ruby -e "puts 'Ruby is fun'" wouldn't be very interesting now, would it?
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 |
The strength of open source software tends to be it's weakness when it comes to security. The problem with OSS is that successful projects tend to grow at an alarming rate with new features being added by the minute (ok... a bit of exaggeration here) without the full ramifications of each new feature being fully evaluated and understood. That is the very enemy of software security.
When was the last time that YOU did a security audit of the Linux kernel, of Apache or of MySQL? Even if you wanted to do a full audit of one of these projects, by the time you would be finished the audit, new features would have been added, taking away some of the relevance of your audit.
On the other hand, in a closed source environment like in most big software houses, new features are added at a slower rate due to the layers and layers of management that usually have to be traversed before the new feature is finally approved to be included into the next release. This gives code reviewers a bit more time to evaluate these new features as well as determine their impact on the overall security of the product. Furthermore, large corporations do tend to take security a bit more seriously these days and are more likely to include the security team at each phase of the development because CEOs have finally understood that a security vulnerability in one of their wares can undermine the entire reputation of their product and company. This is especially applicable to startup companies.
The bottom line is: Sure, small OSS projects are easier to audit as they are small in code size and new functionalities are added at a more reasonable rate. However, when the project tends to have larger pool of contributors, some of which not being educated in software security, things can get messy pretty quickly.
If I can't see the code myself, I am forced to trust that the vendor has refrained from inserting a backdoor in the code. As for third party audits, I trust them as much as I would trust Microsoft to hire an impartial third party to determine whether a new Office version actually increases productivity.
I don't care how many pictures of keys, keyholes, locks, policemen, security guards, castles, gates or agents in glasses the website hawking the product has, how high it ranks on cnet, how many recommendations it gets by editorial staff in magazines, or how many times superlatives ("military grade", "256 bit", "tinfoil hat", "for the ultra-paranoid"), are used in conjunction with the word "security" in a review or the product description. IF I CAN'T SEE THE CODE, I DON'T TRUST THE APPLICATION. PERIOD.
The next level above that is code that I can see - typically open source. At least then it is theoretically possible that someone could get caught inserting a backdoor, with resulting impact on their reputation. Compiling it yourself should be more secure than using something compiled by someone else. One should also consider who is writing it, and who has provided funds to write it. Should I trust them?
Above that is open source code that someone I trust has audited or written.
And above all is code that I have personally written.
Obviously there are trade-offs to be made (usually the only software available to me for my budget is either commercial or open source), but that's how I do the ranking.
Maybe it's time to re-read the classic "Reflections on Trusting Trust". http://www.acm.org/classics/sep95/
If I have seen further it is by stealing the Intellectual Property of giants.
All security *is* obscurity.
Just as all humans are ultimately cellular organisms, or all substances are ultimately subatomic particles. Security is the art of keeping something hidden by requiring something else that is hidden to reveal it, and repeated applications of this principle in various distinguishable implementations.
The lock on a door is only as secure as the secret of where it's key is. Discover this secret, and act upon it, and the secret of the door is revealed.
Likewise, my encrypted email is only as secure as the secret of the contents of my secret key (which is only as secure as my login), and my passphrase.
Even a biometrically secured system is only as secure as the secret of where the user's body is and how to get it to the scanner.
I used to join in on the laughter of "security through obscurity". Then I realized how much of security really is just obscurity, and how it was often not much less practically effective than "real" security. Then I saw that this is because they are ultimately the same, merely in various complexities.
Terrorists can attack freedom, but only Congress can destroy it.
In court, Microsoft claimed that exposing their source would endanger national security.
A couple years later, after the trial was over, Microsoft gives in to Chinese government demands for the source code.
You really think that this kind of 3rd-party review is good? Hint: it is highly unlikely that the Chinese government would report any interesting discoveries back to Microsoft.
The text labels on those graphs are illegible.
If you need text styles to communicate then you don't have a message.
I think that beeing dependent on the software vendor beats any advantage (if there are any) that closed-source may have.