Closed source more secure than open source
Ross Anderson's paper at http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/toulouse.pdf has been mostly discussed for what it says about the TCPA. But the first part of the paper is equally interesting. The author analyzes the security implications of software development using open source vs closed source. He sets up a mathematical model for the number of bugs remaining after a certain amount of testing. Based on this model, he finds that both open and closed source development methodologies are equally secure. However his model has some simplifications and assumptions which are quite unrealistic. A more careful analysis will show that closed source is the superior development method. Essentially, the model assumes that each bug has a certain independent probability of being found by testers, its own "MTBF". Based on this model it turns out that the probability of a security failure after time t is inversely proportional to t. He then writes, "Consider now what happens if we make the tester's job harder. Suppose that after the initial alpha testing of the product, all subsequent testing is done by beta testers who have no access to the source code, but can only try out various combinations of inputs in an attempt to cause a failure. If this makes the testers job on average L times harder, so the bugs are L times more difficult to find... then the probability that the system will fail the next test is..." inversely proportional to t*L. "In other words, the system's failure rate has just dropped by a factor of L, just as we would expect." The result is that, with access to the source code, bugs are L times easier to find, but they are removed L times faster. This corresponds to the open source model. With closed source there is no access to the code, bugs are removed L times slower, but they are L times harder to find. The net result is that both open source and closed source are equivalent in terms of how fast bugs are found, therefore both will be equally vulnerable to exploiters of security bugs. There are several problems with this analysis. First, it is really not true that external beta testers will be slowed down significantly by lack of access to source code. For most programs, source code will be of no benefit to external testers, because they don't know how to program. Someone who is testing a spreadsheet or word processor will have virtually no benefit from access to the source code. They will have no choice but, as described above, to "try out various combinations of inputs in an attempt to cause a failure." This is true regardless of whether the source code is available or not. Therefore the rate at which (external) testers find bugs does not vary by a factor of L between the open and closed source methodologies, as assumed in the model. In fact the rates will be approximately equal. Another problem is that there are really three groups of parties involved here: developers, external testers, and attackers. Attackers, who are trying to find breaks in software, are often highly motivated and skilled. They can read code. For them, the factor of L does come into play. If they have access to the source code, they can find bugs L times faster than if they don't, in accordance with the author's model. The result is that once a product has gone into beta testing and then into field installations, the rate of finding bugs by authorized testers will be low, decreased by a factor of L, regardless of open or closed source. But the rate of finding bugs by unauthorized, skilled attackers will be affected by the availability of source. Closed source will impair their effectiveness by a factor of L, just as with the testers, so the model in the paper is accurate in that case. Bug open source benefits attackers; they can find bugs at a rate of 1/t, while the authorized testers are finding bugs at the slower rate of 1/(t*L). The open source case will leave more bugs available for attack, and the attackers can use the source code to find them more quickly. Therefore open source is more vulnerable to attack, and closed source is the superior development method. The one class of programs where this is not true would be those for which the external testers benefit from having source available, which would be programs where the testers are programmers; i.e., development tools. For these programs the testers and attackers would both be affected in the same way by availability of source. But for most programs, attackers will gain much more by having source available than the beta testers would.
----- Original Message ----- From: "Anonymous" <nobody@remailer.privacy.at>
Ross Anderson's paper at http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/toulouse.pdf has been mostly discussed for what it says about the TCPA. But the first part of the paper is equally interesting.
Ross Andseron's approximate statements: Closed Source:
"the system's failure rate has just dropped by a factor of L, just as we would expect."
Open Source: bugs remain equally easy to find. Anonymous's Statements:
For most programs, source code will be of no benefit to external testers, because they don't know how to program.
Therefore the rate at which (external) testers find bugs does not vary by a factor of L between the open and closed source methodologies, as assumed in the model. In fact the rates will be approximately equal.
The result is that once a product has gone into beta testing and then into field installations, the rate of finding bugs by authorized testers will be low, decreased by a factor of L, regardless of open or closed source.
I disagree, actually I agree and disagree with both, due in part to the magnitudes involved. It is certainly true that once Beta testing (or some semblance of it) begins there will be users that cannot make use of source code, but what Anonymous fails to realize is that there will be beta testers that can make use of the source code. Additionally there are certain tendencies in the open and closed source communities that Anonymous and Anderson have not addressed in their models. The most important tendencies are that in closed source beta testing is generally handed off to a separate division and the original author does little if any testing, and in open source the authors have a much stronger connection with the testing, with the authors' duty extending through the entire testing cycle. These tendencies lead to two very different positions than generally realized. First, closed source testing, beginning in the late Alpha testing stage, is generally done without any assistance from source code, by _anyone_, this significantly hampers the testing. This has led to observed situations where QA engineers sign off on products that don't even function, let alone have close to 0 bugs. With the software engineers believing that because the code was signed off, it must be bug-free. This is a rather substantial problem. To address this problem one must actually correct the number of testers for the ones that are effectively doing nothing. So while L is the extra difficulty in finding bugs without source code, it is magnified by something approximating (testers)/(testers not doing anything). It's worth noting that (testers) > (testers not doing anything) causing the result K = L*(testers)/(testers not doing anything), to tend towards infinite values. In open source we have very much the opposite situation. The authors are involved in all stages of testing, giving another value. This value is used to adjust L as before, but the quantities involved are substantially different. It must be observed, as was done by Anonymous, that there are testers that have no concept what source code is, and certainly no idea how to read it, call these harassers. In addition though there are also testers who read source code, and even the authors themselves are doing testing, call these coders. So in this case K = L*(harassers)/(harassers+coders). Where it's worth noting that K will now tend towards 0. It is also very much the case that different projects have different quantities of testers. In fact as the number of beta testers grows, the MTBD(iscovery) of a bug must not increase, and will almost certainly decrease. In this case each project must be treated separately, since obviously WindowsXP will have more people testing it (thanks to bug reporting features) than QFighter3 (http://sourceforge.net/projects/qfighter3/ the lest active development on sourceforge). This certainly leads to problems in comparison. It is also worth noting that it is likely that actual difficulty in locating bugs is probably related to the maximum of (K/testers) and the (testers root of K). Meaning that WindowsXP is likely to have a higher ratio of bugs uncovered in a given time period T than QFighter3. However due to the complexity of the comparisons, QFighter3 is likely to have fewer bugs than WindowsXP, simply because WindowsXP is several orders of magnitude more complex. So while the belief that source code makes bug hunting easier on everyone, is certainly not purely the case (Anonymous's observation), it is also not the case that the tasks are equivalent (Anonymous's claim), with the multiplier in closed source approaching infinite, and open source towards 0. Additionally the quantity of testers appears to have more of an impact on bug-finding than the discussion of open or closed source. However as always complexity plays an enormous role in the number of bugs available to find, anybody with a few days programming experience can write a bug free Hello World program, but it takes significantly more effort to write something the complexity of Windows or Linux bug-free. That is where open source receives the biggest boost, where Microsoft has a limited number of software engineers, and the Linux development process which has fewer testers but many more developers. This will reduce the number of bugs simply due to the effort put into the process by developers. Which is better? That depends entirely on your situation. Joe
At 06:31 PM 07/06/2002 -0700, Joseph Ashwood wrote:
First, closed source testing, beginning in the late Alpha testing stage, is generally done without any assistance from source code, by _anyone_, this significantly hampers the testing.
This has led to observed situations where QA engineers sign off on products that don't even function, let alone have close to 0 bugs.
I don't know where *you* develop software, but anywhere I've been or seen that had QA engineers signing off on non-functional products would either lead to serious re-education for the engineers or an internal understanding that the company values ship dates above capabilities (not that that's unknown in the industry, and admittedly closed-source development shops are more likely to have business models that emphasize shipping, but Darwin fixes them.) One of the purposes of having QA people work without source is so that they're actually testing documented functions of the product, rather than testing what the code looks like it can do successfully. Except for those products that are code designed to be integrated into other programs, where actual code matters, that modularity is critical. You test the interfaces, not the innards. It's still an infinite problem, but it's much less infinite, and lets you hit what you need. If the interfaces don't work, you're supposed to figure that out, though sometimes late-alpha code is known to be missing major pieces -- you usually work around this by writing lots of test drivers. You're also supposed to find out if there are missing pieces that somehow escaped the design phase. White-box testing lets you go beyond that to find subtle nasty bugs that escaped unit testing and developer code reviews, and have a better view into holes in the system that a malicious attacker can break. It's important for security, because there are often things you don't find during black-box testing.
With the software engineers believing that because the code was signed off, it must be bug-free. This is a rather substantial problem.
A much more serious problem is coders and testers believing that the design documentation they're working from, if any, reflects what the system is supposed to do and what it's supposed to not do.
To address this problem one must actually correct the number of testers for the ones that are effectively doing nothing.
In commercial code with internal testers, you're not supposed to need this. Obviously, for community-tested code, duplication in code coverage is common, and one challenge for the open-source business is finding ways to improve test coverage in volunteer testing, by adding some kind of coordination.
participants (3)
-
Anonymous
-
Bill Stewart
-
Joseph Ashwood