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
    holiday season.

If you want to read the new policy you can find it in our Knowledge Base.

    ISC Security Vulnerability Disclosure Policy:


Michael McNally
ISC Security Officer
bind-announce mailing list

Reply via email to