By now you're surely aware that Microsoft and five other companies (Guardent, Foundstone, BindView, @stake, and Internet Security Systems) have teamed to draft a proposal that they hope will become an industry standard for handling security vulnerabilities after a process of review through Internet Engineering Task Force (IETF). As you know, IETF publishes Request for Comments--RFCs. In general, the IETF serves a loosely knit group of people who want to contribute to the engineering and evolution of the Internet. Anybody can take part by attending any of the three yearly meetings.
Last week, I spoke with Scott Culp, Microsoft Security Program Manager, about the new proposal. Culp reminds us that we live in critical times and need to protect the Internet as best as we can. Microsoft thinks its effort to guide a team in developing an RFC for handling vulnerabilities is a good move. If we don't organize as an industry, some other governing body might step in to do it for us.
http://www.microsoft.com/technet/security/news/standard.asp
As the driving force behind the impending RFC, Microsoft chose the participating companies based on their "sterling reputations" in the arena of security-vulnerability information release. Culp said that the draft proposal recommends building a three-tier network of entities that would receive vulnerability information in phases, from the top down. The team hopes that the process will work by first having a discoverer report its findings to the vendor involved. The RFC would then define how the discoverer and the vendor would handle the information and how the remedy process should occur. Although nothing is written in stone at this point, the plan's intent is to give vendors the right to receive ample information and to thoroughly research the vulnerability while interacting regularly with the discoverer to keep the discoverer informed of any impending remedy. Vendors would have a certain number of hours to respond to a discoverer about any new report. The vendor would have a defined level of responsibility to report findings and would need to give status updates at regular intervals, probably to the top-tier network members and to the original discoverer. After the vendor and discoverer resolve the problem, the vendor would release information to the public about how to remedy the problem (whether through configuration changes or patches). Thirty days after releasing the information, the discoverer would be free to release the full scope of any findings.
But there might be a catch: Although the idea is to prevent someone from unnecessarily arming potential intruders with tools and information that could lead to serious damage, we might find that the RFC proposal includes wording that strongly suggests limiting someone's ability to release source code, as new vulnerability reports so often do. I talked with Culp about this point, and he agreed that many people learn vast amounts of information by having this code available. Such information helps people learn how to better defend their networks and how to write better code so that their programs aren't so vulnerable. The trick might be to figure out how to support time for vendor research without eliminating a person's ability to teach others about a new vulnerability.
I don't know how the team will deal with this concern because the RFC draft isn't available yet. The team participants at @stake are writing the first draft based on group meetings, and the folks at @stake have been prone to offer great detail about vulnerabilities they discover. So it should prove interesting to see their input about full disclosure.
The question is--how can we take reasonable, moderate steps to help prevent someone from turning any sort of work factor (source code, detail explanations) into a weapon of destruction? The idea is to exchange information without delivering a step-by-step blueprint or a working model that malicious users can use as a weapon. Individual discoverers need to think carefully about the potential ramifications before deciding how to handle vulnerability reports. Microsoft believes that by the time that the team runs the proposal through an RFC process, the companies that helped draft the RFC will have been practicing the proposed standards for some time. Culp also said that consumers hold the key to the success of any impending RFC about full-disclosure practices because they can pressure vendors to comply: If a vendor doesn't comply with any full-disclosure RFC, customers might not buy the vendor's products.
If you feel left out of the process, remember that you can help. According to "The Tao of IETF" (available at the URL below), anyone can register for and attend any meeting. According to section 1.3 of the document, "Anyone who plans to attend an IETF meeting should join the IETF announcement mailing list, [email protected]. This is where the team posts all of the meeting information, Internet Draft and RFC announcements, and Internet Engineering Steering Group (IESG) Protocol Actions and Last Calls. People who would like to 'get technical' may also join the IETF discussion list, [email protected]. This is where discussions of cosmic significance are held. (Working Groups have their own mailing lists for discussions related to their work.)" You can read more about the lists in the document at the IETF Web site.
So, regardless of who leads the charge, consider joining the mailing lists and attending the meetings! If you don't, you'll have no room to complain about the proposal later.
Until next time, have a great week.
Mark Joseph Edwards, News Editor, [email protected]
