A new set of OIS vulnerability guidelines [LWN.net]

The Organization for Internet Safety has announced the availability, in draft form, of its "Security Vulnerability Reporting and Response Guidelines." These guidelines offer suggestions for how security researchers and software vendors should work together to deal with security problems in the most effective way. Comments are being solicited for this version; they will be accepted until July 16.

The guidelines, for the most part, make sense. Essentially, they say that things go as follows:

A researcher finds a problem.
That problem is communicated in a clear way to the relevant vendor.
The vendor responds, and the two agree on a timeline for investigating the problem and, if warranted, developing a fix.
The two talk to each other while this is going on.
When the fix is complete, the vendor makes it available, and both parties can release advisories.
Detailed information on the vulnerability is to be withheld for 30 days.

Of course, it takes the OIS 23 pages, many dozen sub-objectives and contingencies, and several complicated flow charts to communicate the above.

The OIS and its guidelines have come under significant fire recently. Many people distrust the OIS after having seen its list of members: @stake, BindView, Foundstone, Guardent, ISS, Microsoft, NAI, Oracle, SGI, Symantec, and our old friends the SCO Group. There are no independent researchers: OIS policy explicitly excludes them. There is also no representation from the free software community. In fact, the OIS is not that impressed with free software in general:

We believe the software author should be given a chance to create a fix before vulnerability information is made public, but that there should be no further distribution of that information until the fix is complete. This priniciple [sic] can be very difficult to adhere to in certain situations, such as dealing with the open source community where there aren't protections to keep vulnerability information secret.

In recent times, the community has shown itself to be quite capable of keeping vulnerability information under wraps for the time it takes to generate a fix. If you want to do that, though, it is imperative to create the fix quickly. The vendor-driven OIS standards seem more oriented toward keeping vulnerability information secret for as long as possible.

The OIS claims that it has no intention of promoting legislation which would codify its guidelines. Given the nature of some of the companies involved, not everybody believes that claim. Certainly any attempts in that direction should be watched for and resisted.

Perhaps the most interesting perspective on the OIS is this, however: there are no free software organizations or vendors represented because the community has no need for the OIS. As a general rule, vulnerability reporting and response works very well in the free software world. Vulnerabilities are reported to the relevant parties, and a whole set of independent vendors and projects gets fixes out quickly. It is hard to see problems in this aspect of our performance which are amenable to any sort of improvement via a set of official guidelines. Our problems, instead, lie in the fact that we create far too many vulnerabilities in the first place. The OIS is not going to help us with that.

(Log in to post comments)