IDG News Service - TORONTO - 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 later. 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
Free Insider GuideCopyright © 1994 - 2012 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
