ISC Security Vulnerability Policy Updated

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