Everybody knows that the software industry is plagued with bug-ridden code. There's been quite a bit of discussion about who to blame - the developers, the vendors, project managers, the customer, etc. In general, it would seem that market forces favor insecure software - for example, if company A provides software with the same functionality as company B, who is favored in the marketplace: the comapany that releases first to market or the company that spends an extra 6 months in dev and QA? How about the company that has the inexpensive, buggy software vs. the company with the more expensive secure software? Note that I'm not saying "blame the customer" here; how can the customer be expected to make this kind of choice when some software is "more expensive and more secure" and other software is just "more expensive." Some would say use a "big buyer" mentality, but I'm curious - how can the buyer know what is more secure and what isn't? What metrics do they have to go by? None... Hence, they can't make that kind of buying decision.
However, inside a vendor or any company that writes software, insecure code is costly which is a driving factor to keep the bug-rate down. There are two approaches I see proposed for increasing the secuirty of code, neither of which work long-term. The first is "educate the developers." This is doomed to failure for two reasons: first, natural turnover decreases the value of the educational investment over time. Second, new types of attacks are discovered every year or so that obviate existing training (for example, if I train all the developers not to use strcpy() and then the strategy shifts to pure-Java.) The other approach is code scanning; this approach is afflicted by problem #2 (e.g. the scanning tool has to be kept current to account for new classes of attacks) but in addition, the tool requires re-running anytime modifications are made to the software (not always feasible depending on type of software being written.) For example, a web-site content change could introduce a problem, maintenance releases need to be scanned, etc., etc.
The way to fix this problem is to invest in strategies that make the "recitivism" rate (the rate of introducing new problems to the code) go *down* over time - e.g. invest in processes, frameworks, and approaches that increase security over time rather the provide a one-time "boost" to the software security baseline. For example, have a development team invest time in a secure framework that makes it easier to write secure software rather than insecure software. This can be done; I'm not going to give out all the secret-sauce here because it's too long, but I will be putting some how-to examples in our book.
I leave you with the optimistic message that code-scanning and training (or a combination of the two) is likely to decrease in usefulness over time, but investment in self-reenforcing processes and secure frameworks are likely to increase over time.
Posted by Ed at March 4, 2005 05:30 PM