Fog Creek Software
Discussion Board

World's Worst Misinterpretation of The Mythical Ma

While Scott Rosenberg's article could have been better written, IMO - (I do consider it humble, but I won't start a fight with any of the acronym warmongers), his article is very much to the point. 

The claim that "Reviewing a large body of existing code to find security problems is easily divided up among huge teams of people, and should not suffer from any of the Mythical Man Month problems." is plain wrong; and with all respect to Mark Seiden, the statement that "it doesn't apply. There are no interdependencies to speak of." is also plain wrong.

Common security problems, like buffer overflows in the input parsing routines can be discovered by "locally" observing a piece of the code. This is also the case of many unchecked input and code injection techniques. However, security does not end there - there are MANY interdependencies which require comprehension of the entire system in order to identify the security problems.

For example, if I correctly understand [ ], one would need to have a good grasp of many interdependencies in the system (proxy, cache, dom, java) in order to locate this bug. By which I don't mean that one person needs to do the entire code review, of course - but that much like in the development process, man hours are not an additive quantity. Don't discredit this bug as being "unimportant" - if I have a competitor behind a proxy (most of Corporate America is), and they looks at my website (perhaps on a daily basis), I can use it to spy on what else they're doing, e.g., everything on their web based CRM. Not as far fetched as you think.

Netscape hadthe same kind of problem: [ ]. And while you may be inclined to think by these two example that this is strictly related to Java, it isn't; Both Netscape and Explorer have lots of cross-frame and local file access vulnerabilities having nothing to do with Java. Another example recently discovered, [ ] states that using Word as Outlook's default editor introduces vulnerabilities. Could a local review uncover those? About as well as as a "local" design and implementation of part of a system will function well, which is to say "hardly". Good design/implementation DOES break into many orthogonal tasks, but they are not independent in the sense that it's really possible to do one without any regard for the other. A security review does is not nearly as orthogonal because, as opposed to design in which one component can compensate for flaws in another, in a security context every module exposes the flaws of any module it interacts with.

Many vulnerabilities are a result of "expectation mismatch" - One part of the system expects things to behave one way, and another part expects a different behaviour. Most of the time, they both agree and there's no problem - however, boundary conditions make these mismatches visible, and when you have similar but not equivalent semantic systems, this becomes harder to notice. Many browser security problems are a result of a mismatch between JavaScript, the DOM security model, and the Java security model. They're close but don't match perfectly. I expect this kind of security problems to proliferate in .net because of the similar but not equivalent semantics of the programming languages.

Another kind of problem is a security design flaw; No amount of review can solve that one, and sometime no reasonable effort can. Practically every networked NT/2K machine (PDCs included) can be tricked to disclose all names and most information about the users and groups it knows. Microsoft tried to solve this with the RestrictAnonymous=1 flag in NT4SP4, but all they succeeded was in requiring a slightly more elaborate technique; They tried to solve it with RestrictAnonymous=2 in Win2K, but the net result is a system that is so awkward to use that practically no one uses it. This is the kind of flaw that no "McDonald" style cooking can discover (Microsoft in general is a McDonald shop - 5000 people working on Win2K can't be Naked chefs, especially because they aren't british).

Security reviews (and security in general) is a QA work, but one that requires exceptional skill and that has, to date, no proven practically applicable methodology or effective tools. It's a Naked Chef style business.

Adding more workers to an already late security review project usually doesn't make it later any more that adding more QA people to an already late QA job makes it later. But does it make it any shorter? Yes, with a significant degradation of quality in both accounts; However, since quality is not really quantifyable (and security even less so), this is rarely noticed.

The industry experience is that Robustness, Security and Efficiency have so far failed to be applied retroactively; See e.g., postfix vs. qmail vs. sendmail vs. Exchange vs Domino in terms of robustness, security and efficiency. IIS 6 stands a chance to be secure mostly because it is a complete ground-up rewrite. And, in case you wonder - despite the aforementioned, I tend to take Joel's side about rewriting, but for mostly different reasons than Joel does [But this essay's long enough - I may write about that some other time]

Ori Berger
Wednesday, May 01, 2002

It seems to me from a reading of Rosenberg's article that, ultimately, he was making an assertion about Microsoft's corporate culture. I'm not sure whether the explanation of Brooks' principle is particularly applicable to his central argument, and so perhaps it should have been left out. The central argument, though, seems to be summed up in this paragraph:

"In this view, the total number of 'man-years' of security code review is largely irrelevant. No matter how smart Microsoft's developers may be, they are all part of one company's culture."

In other words (so his argument goes), there is a limitation to closed code review models that open code review models don't have, and that limitation can't be overcome by throwing lots of programmers from the same corporate culture at the problem.

He's invoking Brooks, I suspect, because he's contending that throwing more people at the problem is a marketing tactic against open source--pointing out that Microsoft usually has more developers on a given project than open source developers do on a comparable project. Since we're talking about code reviewers, not developers, it's argued that that's irrelevant--open source projects (in theory) have more code review done by more people with more greatly varied backgrounds.

Joel seems right in asserting that this isn't a correct application of Brooks' Law--as Rosenberg points out (but fails to see all the implications of), development and code review aren't identical. That observation doesn't address Rosenberg's actual argument, though.

Watts Martin
Wednesday, May 01, 2002

I think Rosenberg's thesis is not valid, and that his article reveals an excessive sensitivity regarding open source. I don't see any suggestion that Microsoft's announcement represented an attempt at one-upmanship over open source.

As to the merits of the Microsoft plan, I see no problems with it. Microsoft has a lot of software to review, and a lot of experience in componentisation and modular development.

That said, I commend Rosenberg for addressing serious issues in software development.

Hugh Wells
Thursday, May 02, 2002

"As to the merits of the Microsoft plan, I see no problems with it. Microsoft has a lot of software to review, and a lot of experience in componentisation and modular development"

Unfortunately, as far as security goes, their track record leaves much -- way too much -- to be desired. Component design the way MS did it so far is anything but secure.

And while I agree that Rosenberg's thesis may be wrong, the conclusion isn't. There is a _huge_ problem with Microsoft's plan, which I tried to touch upon earlier - security review is a job for security people.

There's a world of difference between production (software engineering, in this case) and security - they share little and are in fact complementary. Production is about getting what is in the spec to work; Security is about getting whatever isn't in the spec not to work. (Credit goes to my friend and colleague Oren Tirosh for this distinction). Whereas construction is a problem solving job (we need to get from point A to point B through A1 and X, without passing through C in the middle), and thus subject to use of tools like Methodology and the McDonald cooking manual, security is about finding the blind spots, and no methodology so far has proven useful in that area (and I suspect none never will).

Construction techniques sufficient for creating a product are reasonably well supported by a bounded set (and not a particularly large one). Security, being the complement of production with respect to the entire world, is not bounded, not constructive, and definitely can NOT be learned in a one month crash course. The most such a concentrated course can give is awareness; but given the length of the (bad) track record MS has with security, it appears that awareness wasn't the problem - rather, it was ability, and this isn't something developed in one month (or, for some people, ever).

Ori Berger
Thursday, May 02, 2002

I think Rosenberg was entirely correct in his interpretation of _The Mythical Man Month_.  It's not that security analysis can't be parallelized (given enough eyes, all bugs are shallow) -- it's whether Microsoft can parallelize its work in such a short time frame.  As a coworker of mine once quipped, "what's a 'Microsoft Man-Month?'  It's 60 people working till lunch!"  The corporate logistics of rallying thousands of developers to stop their work and focus on security issues for only two months is a nightmare, and bound to result in pointless thrashing and great gobs of underutilized engineers.  If Microsoft is really going to get serious about security, they're going to have to do a lot more than just this.

Since engineers aren't interchangable and vary so much in ability, it makes even less sense to compare the productivity of Open Source volunteers and Microsoft employees merely in terms of man-years of effort.  And that's Rosenberg's entire point: you can't make a comparison on this basis; the only REAL comparison is comparing how many bugs get found, their severity, and how quickly they get fixed and patches distributed.

Thursday, May 02, 2002

>And that's Rosenberg's entire point: you can't make a comparison on this basis; the only REAL comparison is comparing how many bugs get found, their severity, and how quickly they get fixed and patches distributed.

But there's a problem with that measure as well. More bugs will be found on Windows because the user base is a couple of orders of magnitude larger (okay, maybe less for servers...)

This is the silly thing about the "thousand eyes" idea from open source. Yes, for code analysis, Linux has had more eyes examining it for bugs. But what about black box testing of the actual behaviour? Windows has a HUNDRED MILLION eyes doing that!

That said, I found a bug in Notepad on Windows XP today, so that totally destroys my point.

Run Notepad and type in this text:

hi moe how are you

No newlines. Save it as text.txt, and close Notepad. Now double click the new file. What do you see?

Daniel Earwicker
Friday, May 03, 2002

Ididn't see anything wrong.  What was I supposed to see?

Friday, May 03, 2002

As this is off topic, let's take it outside :)

Daniel Earwicker
Friday, May 03, 2002

Daniel, black box tests only discover the shallower bugs.  And a much larger percentage of the "black-box" end users on Unixes and Linuxes report bugs they find than do Windows user.

You're repeating MS propaganda about software security, which I think originates at Craig Mundi's office - "there are more bugs found because Windows is more popular". Well, IIS vs. Apache is an excellent counterexample - Apache is more popular, yet it's been years (literally!) since the last significant security problem with Apache was discovered.

Ori Berger
Friday, May 03, 2002

Given that the most common security exploit for MS software is the buffer overflow, and that it's possible to specify common coding problems that allow this to happen, I could see MS giving all of their developers a checklist for this and maybe a few other obvious secure coding criteria. Then they tell everyone "go inspect your code and take care of these things." With this approach they may be able to address 50% or even 70% of their security problems. (I can hear the cynics saying "ah, but what's half of infinity?")

On the other hand, I agree with what others have said; without significant training it would be impossible for MS to handle more subtle security issues in a massively parallel fashion.

Greg Compestine
Monday, May 06, 2002

*  Recent Topics

*  Fog Creek Home