Opinion
It used to be we lived in a world with only two certainties: death and taxes. Now it seems there is a third: insecure software.
Bruce Schneier, renowned cryptologist, CTO of Counterpane Internet Security Inc. and security expert, recently told me, in no uncertain terms, that all software is crap when it comes to security. Others have joked that the ultimate oxymoron is not “military intelligence,” but rather “secure software.” The sad fact is the jokes may be true. After all, a quick visit to the Carnegie Mellon CERT Coordination Center Web site – one of the best sites for security information on the Net – and you can find a list of 514 vulnerabilities for Microsoft products. Oracle has 178. They are by no means the only guilty parties, but as the largest software vendors in the world, their security holes affect the most users.
Free market capitalism is supposed to be the closest the business world gets to a pure Darwinian existence. So with security currently all the rage, one could assume those companies with the most secure technologies would prosper the most. But the evolution of technology has taught us that it is not always the fittest that survive, it’s the fastest.
Herein lies the first problem, also known as tech marketing 101. Whatever it is you are trying to sell, get it to market before the competition. Bug fixing can be done at a later date. This thinking seems to dominate among software vendors. Until recently.
A conversation with Mary Ann Davidson, the chief security officer with Oracle Corp., did a relatively good job of convincing me that maybe the tide is changing. Maybe.
Her logic is that the recent U.S. federal government policy to buy only security-evaluated software will force companies to change their focus from time to market to security. After all, it is the only customer left that still has “big bucks” left to spend on IT, with enough buying power to move an entire market.
But how will this change problem two? The most common security crack is the result of buffer overflow, which causes about 80 per cent of security vulnerabilities. But even Davidson admits that stopping buffer overflow by checking boundary conditions is a skill that should be learned in coding 101. So if all developers know how to prevent it, why do we still see it all the time?
There seem to be several reasons behind this. The first is the hardest to change – companies need to adopt more of a security culture. Bill Gates’ famous leaked e-mail about changing the culture at Microsoft to one focused on security may eventually pay off, but if the number of security patch downloads for Windows XP is any indication, success is a long way off.
Coding languages are also often held accountable. James Gosling, a fellow at Sun Microsystems, once told me the key to correcting the overflow situation is to program with Java. But the likelihood of Java being the lone development language is zero.
The last of the coding problems may be the easiest to tackle. Davidson said she has yet to find a really good tool for scanning source code, one that could easily check for buffer overflow. She said the lack of “sexiness” may be why more companies aren’t focusing on bringing a tool to market.
Maybe sexiness is the key. Once security becomes as cool as wireless or the latest Web app then we might start to see more advances made.
Finally, there are those, like Schneier, who want to move the security yardsticks much faster by making companies liable for the products they sell.
This is a pipe dream, at least for the time being. If software manufacturers, for the most part, won’t take liability for their product, even when it is used in the most controlled environments where only certain applications are allowed to interact with certain others, how in the world do we expect them to accept liability when their product has to perform flawlessly in a veritable bouillabaisse of applications?
In hindsight, I guess it is a bit na
