Down To Business: Who's Really To Blame For Software Insecurity?

When it comes to information security, ignorance is anything but bliss, but too much knowledge is daunting. Just when you thought your security team was on top of most major software bugs comes a missive from Gunter Ollmann, director of security strategy at IBM's Internet Security Systems, who maintains in his blog that the 7,247 software vulnerabilities disclosed last year represent only about 5% of the actual total. How much you should worry about the other 95% is a matter of perspective--and practicality.

Of course, IBM's got skin in this game. It's peddling the "pre-emptive protective engines" that Ollmann says are needed to guard against vulnerabilities that don't conform to known signatures. Even so, if his estimate is close to the mark, do we even stand a chance against the attacker hordes?

Just dealing with the known stuff is difficult enough. On a "routine" Patch Tuesday last month, Microsoft issued seven advisories, all of them deemed critical, to fix 19 vulnerabilities affecting Windows, Internet Explorer, Office, and Exchange, as well as its Capicom ActiveX control and BizTalk business process management server. Oracle's most recent security bulletin, in April, included 37 security patches covering its database, application server, and business application suite. Nine of the vulnerabilities covered in the Oracle update let an attacker gain system access without a valid user name and password.

Just last week, researcher eEye Digital Security issued an advisory about 10 critical flaws in CA's client-side backup software that allegedly let attackers take remote control of any networked computer with an IP address that's running the software. After eEye found the first flaw in CA's ARCServe Backup for Laptops and Desktop a few weeks ago, "it just became a landslide," CTO Marc Maiffret told InformationWeek's Sharon Gaudin. "It just kept going and going and going. The software is just that bad." While Maiffret emphasized that CA's security team is on the case, his overall assessment is less than comforting.

Not all vulnerabilities are equal or require public disclosure, notes IBM's Ollmann. Some are discovered internally by the vendor and patched silently. Sometimes, he says, a bug is too "lame" to report.

Presenters at the Gartner IT security summit last week said they take different approaches to disclosing their findings. David Maynor, CTO of Errata Security, said he gives vendors a month to fix software vulnerabilities before he reports them publicly. Thomas Ptacek, a principal with Matasano Security, said he waits for the vendor to make its own public disclosure before he publishes a vulnerability report. Other researchers just fire away.

But perhaps we're placing too much emphasis on the messengers and the message, and not enough on the protagonists--the developers that continue to bang out software that's rife with security holes and the attackers who exploit them.

The idea of holding developers legally liable for shoddy security isn't a new one, and it could gain momentum given this country's current infatuation with litigation and regulation. Just as California and other states have passed laws that hold companies liable for safeguarding customer data, so too could they hold companies, as well as their software vendors, responsible for inadequate security. At some point, vendors will have to lengthen their development cycles, ratchet back features, and invest in secure development processes as a matter of business survival. If potential litigation isn't enough incentive for developers to get the security religion, perhaps they should consider the cost: Fixing a bug once an application is in use can cost up to 100 times more than identifying the problem during development, Veracode CTO Chris Wysopal said at the Gartner conference last week.

Meantime, let's not lose sight of the real criminals--the miscreants who write the exploits and viruses and carry out the attacks. Make examples of those who are convicted.

Rob Preston,
VP/Editor In Chief
[email protected]

To find out more about Rob Preston, please visit his page.