|
|
| Summary of Changes
from Public Review |
| |
|
| |
The public review period for the
OIS Security Vulnerability Reporting and Response Guidelines ended
on 03 July 2003, and the OIS members would like to thank everyone
who participated in it. Your comments, suggestions, and other
feedback significantly improved the guidelines and helped ensure
that they will meet the needs of the security community.
The released guidelines, which incorporate the results from the
public review, are available at
http://www.oisafety.org/reference/process.pdf. Although we wish
we could provide a mapping of individual review comments to specific
changes in the guidelines, it’s not feasible to do this. In some
cases, the changes represent compromises designed to address
multiple reviewers’ comments; in others, the reviewers asked that
their feedback not be published. However, we are confident that
readers who review the
public
comments will see ample evidence of the comments’ influence in
the published guidelines.
With that said, we can list the major revisions and thematic changes
that were undertaken as a result of the public review. Highlights
are discussed below. (Please note that the discussion uses the
section numbers from the public review version. The section numbers
in the released guidelines may be different due to the revisions).
- Clarifying the context of the guidelines. Many
reviewers felt that the document presented the OIS guidelines as
mandatory for the entire security community, and belied an
assumption that the model they comprise is the only one that could
be followed. This was not our intent. The OIS members recognize
that there are several models for handling security
vulnerabilities, although our shared experience is that the one
outlined in the guidelines has the best track record and offer the
best prospect for success.
With that in mind, we rewrote Section 1.1 (“Purpose”) to more
accurately position the guidelines. Specifically, we noted that a
number of models have been advocated for protecting users, the
Internet, and critical infrastructures against security
vulnerabilities. The guidelines embody one such model, which is
based in the belief that Finders and Vendors can do this most
effectively by working together. The guidelines are therefore not
for everyone, but instead are intended for use by people and
organizations that subscribe to this particular model.
- Reinforcing the severability of the guidelines. Many
reviewers commented that there were some provisions that were
infeasible, inapplicable, or inadvisable for various reasons. A
common misperception was that the guidelines weren’t severable –
that is, that they had to be adopted in full or not at all – and
some of the reviewers therefore concluded that they would be
unable to adopt them.
We made changes throughout Section 1 (“Introduction”), to stress
that the guidelines are not intended to mandate specific business
practices nor do they obligate adopters to take actions that might
be in conflict with local laws. We also added text to specifically
note that the guidelines can be adopted in whole or part. (We do,
however, recommend that adopters fully disclose in advance any
guidelines that they do not intend to follow).
- Clarifying the definition of “supplementary data”. The
public review version of the document was imprecise in its
definition of supplementary data in Section 7.6, and many
reviewers objected to this. We had left the definition imprecise
by design, in recognition of the sizeable gray area that exists
between obviously benign data and obviously sensitive data. We had
intended to create a framework in which adopters could exercise
their professional judgment, with the understanding that customers
or colleagues might challenge their choices. However, a number of
reviewers were concerned that this could allow an overly broad
definition of supplementary data to be used. For instance, several
reviewers were concerned that the document as written could be
interpreted to prevent a vendor from publishing the source code
for its security patches.
We revised Section 7.6 to apply the term supplementary data only
to obviously sensitive data. We made the critical distinction that
supplementary data directly provides the means to exploit the
vulnerability, as in the case of step-by-step instructions or
attack tools. All other data – even data like source code that,
could be analyzed to reveal the means of exploiting the
vulnerability – are outside the definition.
- Making the conflict resolution options more prominent.
Many reviewers felt that the placement of Section 8 (“Conflict
Resolution and Third Parties”) at the end of the document was
incorrect, inasmuch as conflicts could occur and third parties
could be used at any point in the process. We therefore moved
Section 8 in its entirety, and made it the third section in the
guidelines.
- Differentiating between minimum and recommended
performance. Several reviewers were concerned that the
requirements, as written, offered no incentive for a Vendor to
exceed the minimum performance. For instance, when reading the
requirement that the Vendor respond to any Vulnerability Summary
Report (VSR) within seven days, some reviewers interpreted this to
mean that the Vendor had no obligation to respond until the
seventh day.
We made changes throughout the document to rectify these problems.
In general, our approach was to replace turnaround times in the
Vendor’s requirements with a stipulation that the Vendor act as
quickly as possible, and then add a Finder requirement specifying
a worst-case turnaround time. For instance, in the example
discussed above, the Vendor’s requirement is to respond to a VSR
as quickly as possible and the Finder is enjoined to give the
Vendor up to seven days before sending a Request for
Acknowledgment.
- Sharpening the focus of several sections. Some
reviewers reported that it was difficult to understand the scope
of one or more sections. The most commonly cited sections were 5.3
(“Shared Codebases”), 6.3 (“Simultaneity”), and 6.4
(“Internationalization”). We added context-setting text to several
sections, and revised many requirements to be more specific. In
addition, in response to several review comments, we concluded
that Section 6.5 (“Automation”) was dictating a business practice
and so removed it, and we also added a new section to discuss
workarounds.
- Shortening the document. Many reviewers cited the
length of the document as a barrier to adoption. While these
comments were balanced by other reviewers’ recommendations that
the document be extended to provide more background information
and/or specific procedures, we agreed that the document could be
improved if shortened, and undertook several review passes to
eliminate deadwood.
|
|
© 2003 OIS.