The Wall of Fear

Users worry as volume, severity of flaws steadily grow.

The numbers are staggering: 4,129 in 2002, up from 2,437 in 2001. And in the first quarter alone this year, there have been 1,993 new vulnerabilities found. The volume of flaws found has been rising at an alarming rate for as long as people have kept statistics.

As the crushing pace of software development marches on and each successive generation of developers continues to make the same mistakes as its predecessors, the details of the vulnerabilities all begin to run together.

"Wasnt there a big problem found in IIS [Internet Information Services] recently?"

"Yeah. Sounded really bad, too, I think. No, wait. It was IOS [Internetwork Operating System]."

"Have we patched that one?"

"Not sure. Let me take a look."

The constant drumbeat of critical-this-is-huge-patch-it-now-or-be-owned bulletins and the subsequent warnings about exploits being developed and used have combined to form a kind of low hum in the background to which many administrators and IT managers have become immune. This is not a good thing, to say the least.

The recent widespread vulnerabilities in Cisco Systems Inc.s IOS and Microsoft Corp.s RPC (Remote Procedure Call) service in Windows have again sharpened the focus on this problem. Cisco, of San Jose, Calif., took the extraordinary step of warning its largest customers—backbone providers and large Tier 1 ISPs—about the IOS vulnerability before the problem was publicly disclosed. This drew some criticism but seems to have had the desired effect of preventing any large-scale attack on the core of the Internet.

By contrast, the Windows RPC flaw was disclosed publicly in mid-July and was accompanied by dire warnings of imminent attacks against the weakness, which is found in every current version of the operating system. Microsoft, of Redmond, Wash., strongly encouraged its customers to apply the patch, as it always does. But within two weeks, several sophisticated attack tools were being distributed within the security underground, and monitoring companies reported seeing regular coordinated attacks against vulnerable machines.

"The elevated media attention on the potential ramifications of not installing this new patch raises the perceived importance of patch management from a network administration process to a crucial business management issue," said Gary Stowell, vice president of product management and business development at St. Bernard Software Inc., of San Diego. "Companies can no longer afford to take a laissez-faire approach to patching their corporate networks and securing their informational assets."

At a panel discussion on vulnerability handling during the recent Black Hat Briefings in Las Vegas, one of the main lines of questioning was what could be done to encourage, if not coerce, enterprises to patch their systems. Panelists were all part of the Organization for Internet Safety and had a hand in the development of that groups policy on vulnerability handling.

Although the panelists said patching was outside the scope of their current work, they said it might be something theyll look at in the future.

"We know that patching is an issue. And we may have to take a look at that sometime down the road. Theres definitely some room for someone to help there," said Rajiv Sinha, manager of security compliance at Oracle Corp., in Redwood Shores, Calif.

But even if OIS or a similar group eventually develops guidelines for patch management, that would just reinforce what IT staffs already know: Its important to patch your systems. The real problem is finding a way to break through the noise and come up with a system that succeeds in getting people to apply patches.

Its clear that scare tactics and prophecies of doom are no longer doing the trick. But even the relatively new crop of automated patch deployment solutions leaves some IT managers wanting.

"People have been burned by patches that break other services, and so they want to do a lot of testing," said Scott Blake, vice president of information security at BindView Corp., in Houston. "And if something looks like its going to cause problems, they dont use it. Thats the problem."

(Editors note: This story has been modified since its original posting to correct a numerical error.)