ISC Software Defect and Security Vulnerability Disclosure Policy
At ISC, we follow a fixed policy in determining how to disclose defects discovered in our software products. 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 a severity level to determine whether an advisory should be issued and of what kind.
In cases where the severity of the issue (as measured by the CVSS score) 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 optionally issue an "Operational Notification" to inform customers about the issue and advise them how they may deal with it.
For issues with a CVSS score >= 5, where the severity level is rated as "high", "critical", or "critical & catastrophic", ISC will perform a Security Vulnerability Disclosure which, depending on the nature of the vulnerability, may consist of either of two types. We first look at whether the issue is in the public view already and whether or not 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. This process is designed to allow maximum preparation time to our valued customers, as well as providing 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 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 who package our code into their distribution receive an email notice of the disclosure up to 24 hours before planned release of the public disclosure and link to where code will be available.
- Phase Three: Public disclosure of the vulnerability, and release of patched versions of all currently supported affected code. We publish the notice on the ISC Bind mailing lists and on the ISC web site. 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 will 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 will be done. Notification is sometimes prior to 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 will get notification as soon as possible, but not always prior to public announcement.
During a Type II Security Disclosure, ISC will endeavor to contact all critically affected customers and vendors as promptly as possible.
For further information on ISC's Phased Disclosure Process or Security Vulnerability response processes, please contact ISC's Security Officer team firstname.lastname@example.org.
© 2001-2016 Internet Systems ConsortiumPlease help us to improve the content of our knowledge base by letting us know below how we can improve this article. If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback. For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.