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.
| |
At the conclusion of the event, Microsoft was joined by five security firms – ISS, @stake, BindView, Foundstone, and Guardent – in announcing a new disclosure policy that they would adhere to voluntarily. The policy permits immediate disclosure of the existence of a newly discovered security flaw, but the release of complete details would be restricted for 30 days. The coalition reportedly plans to develop a new industry standard on disclosure that will be submitted to the Internet Engineering Task Force.
Situation Analysis: META Group believes that immediate public disclosure of the discovery of potential security vulnerabilities is vital, both to warn system administrators and users and to spur the vendor involved to develop a patch as quickly as possible. In the past, some vendors have hidden the existence of security flaws in their software and essentially ignored their duty to fix those flaws until hackers exploit them to damage users’ computers. Without immediate disclosure, vendors would be tempted to revert to this practice.
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.