ISC Software Defect and Security Vulnerability Disclosure Policy
At ISC, we follow a published policy in determining whether and how to disclose defects discovered in our software products.
This policy applies to all currently-supported versions of our open source products that are recommended for production use. Only the most recent monthly releases of our stable maintenance versions are covered by this policy; please visit https://www.isc.org/download to see the latest releases. The current stable maintenance versions are:
- BIND 9.16 ESV
- BIND 9.18
- Kea 2.2
- Kea 2.4
This policy does not apply to software versions that are end-of-life, end-of-maintenance, or development versions not recommended for production use. Currently those are:
- BIND 9.0-9.14 (any version)
- BIND 9.11 (any version)
- BIND 9.16.n (where n is not the latest monthly release)
- BIND 9.18.n (where n is not the latest monthly release)
- BIND 9.19 (development branch, any version)
- Kea versions prior to Kea 2.2
- Kea 2.3
- ISC DHCP (all versions)
Security Vulnerability Process and Assessment
In each case we assess the severity of the issue using the Common Vulnerability Scoring System, which helps us determine the severity and urgency of the problem. We use the computed score to assess the severity level to determine whether an advisory should be issued and of what kind.
In cases where the severity of the issue (as defined by the CVSS Specification Section 5) is rated LOW or MEDIUM and we are not aware of any deliberate exploit strategy, we are not required by our policy to issue a notification. However, in cases where we are concerned the defect may have substantial operational impact for our users, we may choose to issue an Operational Notification to inform customers and users of the software about the issue and advise them how to deal with it.
For issues with a CVSS score >= 7, where the severity level is rated as HIGH or CRITICAL, ISC will perform a Security Vulnerability Disclosure which, depending on the nature of the vulnerability, may be either of two types. We first look at whether the issue is in the public view already and whether it is causing operational distress. Issues are classed as either Type I (not in the wild) or Type II (in the wild). Having determined the severity level and the type of the vulnerability, our development teams develop fixes for the problem. When possible, we then have the issue tested by the original submitter (in addition to our own internal tests). When the tests are passed, we are ready to begin our phased disclosure process. (In rare cases where the vulnerability impacts multiple disclosing parties, ISC's phased disclosure process may be delayed to coordinate with the other disclosing parties.)
This process is designed to allow maximum preparation time to our valued customers, as well as to provide a public benefit to the security of the Internet infrastructure by giving the security community and our vendors warning that a security disclosure is imminent.
In the event of a Type I Security Disclosure (not in the wild or causing known problems)
Phase One: ISC support customers, including OEMs who re-package our open source into commercial products, receive formal notice and a pre-release code snapshot as far in advance as possible. At this time we also notify the DNS root operators if the vulnerability affects authoritative services. We do this between three and five business days in advance of the public disclosure.
Phase Two: Operating system maintainers receive an email notice of the disclosure up to 24 hours before planned release of the public disclosure and a link to where updated code will be available. This notice is sent to the operating system packager mailing list, firstname.lastname@example.org.
Phase Three: The vulnerability is disclosed publicly, and patched versions of all currently supported affected code are released. We publish the notice on the appropriate ISC software mailing list(s) (BIND 9, Kea, ISC-DHCP). Selected CSIRTs receive an email notice of the disclosure. We notify FIRST.org, CERT.org, US-CERT, CERT-FI (Europe and Middle East), and JP-CERT Coordination Center (APCERT, PacCERT and AfricaCERT).
In the event of a Type II Security Disclosure (in the wild, or causing known problems)
- Phase One: ISC support customers get as much information as we have as quickly as we can safely release it. It is not generally possible to send patched code in advance, but when possible, this is done. Notification is sometimes prior to a public announcement, but not always. Whenever possible, ISC releases code to resolve a Type II disclosure within 24 hours of notification of the problem.
- Phase Two: CSIRTs and operating system packagers get notification as soon as possible, but not always prior to a public announcement.
During a Type II Security Disclosure, ISC endeavors to contact all critically affected customers and vendors as promptly as possible.
When ISC, at our own discretion, believe that an issue could have a significant impact on many or all users of the software, we may notify the the product-specific announcement list (bind-announce, kea-announce, or dhcp-announce) to inform users about our scheduled update release date and time, and the severity of the issues being fixed by the update. The purpose of this is to alert system administrators to be prepared to respond when the issue is made public.
Annual quiet period
In recognition of the common practice of having a "network freeze" during the last two months of the calendar year, when many systems administrators try to avoid making changes, we attempt to avoid issuing any public vulnerability notifications during that time. This of course does not apply to a Type II vulnerability.
For further information on ISC's Phased Disclosure Process or Security Vulnerability response processes, please visit our website.