ISC Security Vulnerability Disclosure Process Update
mcnally at isc.org
Wed Sep 4 20:09:48 UTC 2019
At ISC we are updating our security vulnerability disclosure policy.
Security and transparency remain the primary goals of our vulnerability
handling procedures but we would like to make some adjustments to
better serve our customers and reduce the impact of frequent
out-of-cycle security releases.
Why are we making changes?
Our current vulnerability disclosure policy has been in place for
more than six years. During that time we have had an opportunity
to evaluate the policy and its application to a variety of real-world
vulnerabilities identified in ISC software products and after each
disclosure we have taken the opportunity to examine our handling
of the incident. Based on our experience we think we can improve
the process to schedule security fixes more predictably, avoid
unnecessary alarms, and still ensure that those security vulnerabilities
that constitute a significant risk for our users get patched and
disclosed in a timely manner.
What changes are we making?
1. The most significant change will be to change the threshold CVSS
score at which our policy requires us to go through our full
disclosure process. As it is currently written, the policy
states that we will have a disclosure for any vulnerability
that scores as "High" or "Critical" (or "Critical/Catastrophic",
a category that no longer even exists) but the policy also
states a threshold CVSS value of 5.0, which was initially chosen
based on a previous version of the CVSS scoring system. In
CVSS 3, which we have used since 2017, the "High" and "Critical"
severity categories begin at a score of 7.0, so we propose to
change the threshold value to align with the categories used
by the current scoring system. It is important to note that
this threshold value is used by ISC to determine when a phased
disclosure process is mandatory. We retain the option to issue
a Security Advisory or Operational Notification for issues which
score below this threshold if, in our judgement, the impact on
operators would make such an action advisable.
2. We also plan to begin using the Temporal and Environmental metrics
introduced in CVSS 3.0. These attempt to improve the accuracy
of vulnerability scoring by allowing factors to be taken into
account which are not considered in the Base Metrics. Our
previous policy of not using these metric groups meant that
adjustments due to these factors were set at the most pessimistic
levels even if taking all available information into account
would have resulted in a lower score (for example: a vulnerability
which has an effective configuration-time workaround and does
not require an immediate software update to prevent exploitation
is eligible for a lower CVSS score, but only if one is using
the optional Temporal Metrics when scoring.)
3. Finally, since we are making public changes to our disclosure practices,
we would like to take this opportunity to also introduce a
policy change requested by our customers. Beginning this year,
to the extent possible we will avoid scheduling disclosure of
non-emergency security issues during the period beginning
November 1 and ending December 31. Based on feedback we have
received, many of our customers have special configuration and
change freeze requirements for this period, which can be an
especially important one for retailers and some other types of
business. We therefore propose that if a non-public vulnerability
is discovered by us or reported to us and we are able to do so,
that disclosure of such issues be postponed until after January
1 in order not to interfere with the end-of-year retail and
If you want to read the new policy you can find it in our Knowledge Base.
ISC Security Vulnerability Disclosure Policy:
ISC Security Officer
More information about the bind-announce