News Item: Before its Trusted Computing Forum last month, Microsoft issued a position paper denouncing "the practice of publishing explicit, step-by-step instructions for exploiting security vulnerabilities, without regard for how the information may be used." Microsoft stated that it does not oppose disclosing the existence of security flaws in its software, but that the practice of publishing explicit code details and information about how hackers can exploit the flaws has contributed to the proliferation of damaging computer viruses.
However, we oppose public disclosure of the specifics of how to exploit the potential flaw. Too often, we see third-party security analysts publishing the code they used to penetrate a piece of software in order to gain publicity and sell security solutions. The irresponsible publication of this information forces the vendor to race against hackers to get a patch out that users can implement before their systems are damaged.
Of course, some flexibility to address the needs of enterprise clients is needed. Sometimes system administrators need the more detailed information to build a work-around to protect their systems until the patch is available. However, they should look to the vendor to provide this privately through its support organization.
Ideally, exploit information would be made public only in extreme cases, even after the patch is developed. For example, if a vendor moves very slowly on developing a patch, the discoverer of the security flaw can use the threat of disclosure of exploit information to spur the software maker to take appropriate action. However, the availability of a patch does not guarantee that all users have or are able to implement the fix. In some cases, a patch to an operating system or other low-lying code has created a conflict with a key third-party application, preventing users of that software from implementing the patch until it, the application, or both are further updated.
Because of the potential impact on applications, users need to do extensive regression testing before implementing patches. This takes time and money, and organizations may not have the resources to start testing immediately after each patch is released - particularly in an environment in which patches are common, as is true with Windows currently and may become true with Linux as it grows in popularity. Therefore, even users with strong security programs might remain vulnerable for some time after a solution to the problem is developed and distributed.
We view the new disclosure policy announced by Microsoft and its security vendor allies as a positive step, because it permits immediate disclosure of security flaws while delaying the release of technical details that hackers could exploit. However, the wave of criticism from other security industry players that greeted this announcement is also understandable, given Microsoft's poor reputation and mediocre track record in security matters.
A new industry standard on disclosure developed via a vendor-neutral process that balances the benefits and risks of disclosure would improve computing security. However, if Microsoft uses its clout to establish a de facto standard that lessens the pressure on itself and other software makers to swiftly create and distribute patches for security flaws, the result could be weaker security protection. To keep software vendors honest, prompt disclosure of security vulnerabilities cannot be optional - it must be mandatory.