Immediate flaw alerts vs. Disclosing with patches

Responsible security flaw disclosure debate gets ever more complicated.

What’s safer, knowing there’s a gaping hole that can be exploited in a software product even when there is no patch for it, or being told about the gaping hole once there is a patch? That debate pits the tell-all crowd arguing for “full disclosure” against those who argue for “responsible disclosure.”

What’s safer, knowing there’s a gaping hole that can be exploited in a software product even when there is no patch for it, or being told about the gaping hole once there is a patch?

That debate, heard since the dawn of software, pits the tell-all crowd arguing for “full disclosure” against those who argue for “responsible disclosure,” a philosophy favoring greater discretion about software vulnerabilities in the hope that malicious hackers won’t benefit from too much information.

But that assumes they don’t already know anyway. And if the hackers know, then is it just the good folks who are in the dark? Such have been the powerful arguments on both sides, which grew louder in the 1990s as Microsoft Windows settled in for a long stay on the desktop and server, giving “script kiddies” armed with automated attack tools the ability to hit a lot with little effort over the Internet. It didn’t help that Microsoft in the early days was in a blissful state of near-complete denial about software holes.

At the same time, security research was accelerating, with brash young firms like eEye Digital Security (founded in 1998) discovering vulnerability after vulnerability in Windows, and at the time, arguing for full discovery. Then the real impact of software vulnerability hit home for the entire world when the crippling computer worm named Code Red ripped across the Internet in 2001, exploiting a vulnerability in unpatched Microsoft ISS Web servers.

Although a server patch had been available for a month that could have stopped Code Red if applied to servers, the topic of disclosure grew ever more shrill as some accused eEye of revealing too much about Windows flaws.

In an attempt to find balance in the debate, a group calling itself the Organization for Internet Safety was founded in 2002 by Microsoft and others in the industry to come up with guidelines for responsible disclosure of software flaws. Last updated in 2004, the OIS guidelines say someone discovering a software flaw should discretely share that information only with the software vendor involved, allowing a minimum of 30 days to correct the problem.

But since then, the argument has only gotten more muddied as a thriving industry in the last few years has sprung up for selling information about vulnerabilities directly to security firms, which then market the vulnerability data to subscribers.

Some individuals who once backed the OIS guidelines say they’re antiquated and only useful for protecting software vendors. “The OIS standards were a valiant effort, but in the end the OIS was designed to help vendors manage things on their end,” says Terri Forslof, who helped craft the OIS guidelines when working in Microsoft’s security-response center but joined a security firm re-selling vulnerability research.

Still, others vehemently disagree, saying responsible disclosure in which vulnerability research is shared first privately with the software vendor is ethical, while selling it to subscribers is not. “They’re brokering information that makes the world less safe,” says Kris Lamb, director of the X-Force research development at IBM’s Internet Security Systems division.

< Return to the list of arguments >

Learn more about this topic

 
Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies