How to cheat at the lottery

Ross Anderson Ross.Anderson at cl.cam.ac.uk
Tue, 17 Aug 1999 22:50:34 +0100


An anonymous poster wrote:

> Brooks ("The Mythical Man-Month", ISBN 0-201-83595-9) points out 
> how design is best done by a small number of people, programming by 
> a larger team

He made a very powerful argument that `coding is hard to parallelise'.
OK, but so what? Coding makes up maybe 10% of the effort in a large
software project. Requirements engineering is maybe 30% and testing/
maintenance a massive 60%.

Projects such as Linux have shown that maintenance is often highly
parallelisable. My paper's contribution is to show that requirements
engineering often is too. I don't claim it can _all_ be done in
parallel; but when designing a security system, it will often be
better to hire 15 people for a day each in parallel to think up
possible attacks and then one person to spend a week putting together
the final specification, rather than getting one person to spend a
month (or three) on it. This is pretty much what happens with the
maintenance of large open source systems. The trick is to get the
right balance between the centre and the periphery.

In retrospect, this should surprise no-one. Figuring out what a system
should do often means iterating the specification in the light of
attacks. This process is not all that different from iterating the
design of an operating system in the light of customer complaints.  If
you can get lots of bright people to think up attacks (or complaints)
in parallel before you code up the system, you might save a lot of
money. The economics - of how many man-months of thinking teach you as
much as how many years of field testing - must be determined
empirically, but the experiment I conducted is at least a start.

This aspect of the debate belongs properly in the robust open source
software mailing list, Contact open-source-request@CSL.sri.com to
subscribe.

But there is another aspect which belongs in this list. The Forces of
Darkness would love all security software to be classified, or at
least under strict NDA. Three of the four major smartcard vendors
keep their development kits under NDA; their excuse is that some of
the Common Criteria protection profiles require obscurity of the ROM
software (STM even keeps their CPU opcodes secret). The design of many
pay-TV systems was kept secret, but once the secrets were probed out
of the chips there were obvious and trivial attacks. Clipper was
classified but that didn't stop Matt Blaze finding a protocol failure.
The specifications of SWIFT, CHAPS and all other banking systems are
kept secret - but there's a lot of ISO standards out there with
published attacks on them (nudge nudge wink wink).

Bringing security software development into the open (and preferably
open source) will reinforce the light and undermine the darkness. It
will also result in much better designs. We may care about the former
argument; firms like IBM are more likely to be moved by the latter

Ross