MS says stop discussing hack exploits

Microsoft's security chief has accused the security industry of creating "information anarchy" by openly discussing exploits when security vulnerabilities come to light.

In an essay, Scott Culp, manager of the Microsoft Security Response Center, said that the full disclosure approach to issues taken by the security community does a disservice to end users, and has called for a rethink.

"It's high time the security community stopped providing blueprints for building these weapons", such as Code Red, Nimda or the Ramen worm, Culp writes. "And it's high time computer users insisted that the security community live up to its obligation to protect them."

Culp readily concedes that all vendors have a responsibility to limit security flaws and that security vulnerabilities should be discussed but he takes issue with the "practice of deliberately publishing explicit, step-by-step instructions for exploiting security vulnerabilities, without regard for how the information may be used."

Security vulnerabilities are a fact of life with complex software so the question becomes how we deal with the issue, he states. The "information anarchy" that exists now guarantees the use of vulnerabilities by hackers and other ne'er do wells.

"The relationship between information anarchy and the recent spate of worms is undeniable," Culp said. "Every one of these worms exploited vulnerabilities for which step-by-step exploit instructions had been widely published [and] using the same techniques as were published."

Culp rejects arguments that the publication of vulnerabilities brings pressure on software vendors to fix problems and demonstrate the need for sys admins to take action. Strangely he suggests this publishing exploits works against getting patches out.

Culp also repeats Microsoft's criticism that users are failing to apply patches.

If portions of the security community continue to act in way that abuses free speech (he compares the action of some to "yelling 'fire' in a crowded movie house") then vendors pull back from openly addressing security vulnerabilities and find some [unstated] way of addressing customer issues. What this means (other than a knee-jerk reaction from Microsoft) we've no idea.

Culp's essay, which doesn't have much to say on how to end the threat of worms (in fact he suggests they will always exist) reopens the debate about whether information about security flaws should be controlled, or made freely available in open disclosure mailing lists (such as BugTraq).

We agree with Culp that exploit codes shouldn't be published (fewer tools in the hands of s'kiddies has to be a good thing and we're not convinced exploit codes help people test for vulnerabilities) but disagree with the suggestion that people should hold back on discussing the details of security issues. For one thing, such information can provides ways to mitigate risks before a vendor patch comes out.

The essay labels the whole security community together and fails to say that the main problem lies with people writing worm writing toolkits (such as that which created the Anna Kournikova worm) and black hat hackers writing code.

These are people Microsoft has no hope of controlling and it fails to understand the Internet if it thinks that it, or security vendors, can restrict the flow of information it takes exception to.

Microsoft is always going to be a prime target for hackers and that being so it needs to work closely with the security community when problems are brought to its attention, in fact security vendors tell us it is getting better in that regard.

Perhaps with this increased security awareness (and criticisms by heavyweights such as Gartner about IIS) Microsoft has come to see that it has much to do, hence the occasional need of those most at the front line to vent off their opinions in public.

Let's have closer co-operation between Microsoft (or Linux vendors) and security firms in the interests of end users - not a return to the bad old days when Microsoft used to claim that a particular vulnerability was purely "theoretical"... ®