Whose fault is it? Where should the finger of blame be aimed for the recent spate of virus and worm attacks on Microsoft's Internet Information Server (IIS)? Virus writers? Microsoft? You? Me?
Not so fast, Microsoft says. Security professionals are an ingredient in the blame mixture.
"It's high time the security community stopped providing blueprints for building these weapons," writes Scott Culp, manager of the Microsoft Security Response Center, in an essay on Microsoft's Web site.
Culp decries "information anarchy" which he defines as "the practice of deliberately publishing explicit, step-by-step instructions for exploiting security vulnerabilities, without regard for how the information may be used."
A system administrator doesn't necessarily need to know how a vulnerability works in order to protect his system "any more than a person needs to know how to cause a headache in order to take an aspirin," Culp writes.
Culp has no problem with the discussion of security matters. But a line should be drawn where information can potentially hurt users. "By analogy, this isn't a call for people to give up freedom of speech; only that they stop yelling 'fire!' in a crowded movie house."
Yet some see Microsoft's criticism as a way to deflect attention from IIS' own weaknesses. "The bearer of the message has little credibility on security vulnerabilities," according to Neal O'Farrell, CEO of Hackademia, a firm focused
"If you install crummy locks on your windows, and then only replace each one after someone breaks it, you cannot say that you've done your job," says Robert Vibert, an anti-malware researcher and solution architect with Segura Solutions Inc. and a searchSecurity expert.
Vibert concedes that vulnerabilities are a fact of life but takes issue when known vulnerabilities keep rearing their heads. "If the software companies were to do something radical, like thoroughly test their code for known exploit attacks then fix the holes, we would not have this issue."
Yet Culp's remarks do pose an interesting question: Can there be too much security information? Several security experts interviewed for this story admit that distributing information about vulnerabilities helps virus writers. Their concerns are the vulnerabilities themselves and how to make sure vendors address them.
Andrew Moffat sees this double-edge sword between the need to report the details of vulnerabilities for a patch and aiding virus writers. The problem is that vulnerabilities need to be discussed in vivid detail publicly before some vendors address them.
Disclosure of vulnerabilities is "a stick to wield against" software companies that create a vulnerability that costs users billions, says Jonathan Callas, senior systems architect for Wave Systems Corporation and a searchSecurity expert. "The sad state of affairs is that most manufacturers -- not just Microsoft -- don't take a bug seriously unless it's causing a PR stink."
But the recent Nimda and Code Red attacks targeted known vulnerabilities for which Microsoft already had patches. The massive levels of infection highlight that some users are not doing the patching they should. Microsoft's patching process perhaps wasn't as easy as it should have been, Culp admits. The company announced a new security initiative three weeks ago that will address the issue.
"But if the current methods for protecting systems are ineffective, it makes it doubly important that we handle potentially destructive information with care," Culp adds.
However, curtailing the discussion of vulnerabilities in the security community won't stifle the exchange of such information, experts say. "The hacking community does not need the security community to teach it how to hack," according to O'Farrell. "We're all better at security because of the tough lessons the hacking community is teaching us every day."
FOR MORE INFORMATION:
Should you ditch IIS? Check out IIS: To ditch or not to ditch and decide for yourself.
What's your IIS experience been like? Good? Bad? Ugly? Other? Go to http://searchWin2000.techtarget.com/poll and tell us.