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: DNSco support customers receive formal notice and pre-release code snapshot as far in advance as possible. This is usually between two and five business days in advance of the release of the public disclosure and code.
- Phase Two: CSIRTs and other global security tracking organizations receive an email notice of the disclosure 24 hours before planned release of the public disclosure and link to where code will be available.
- Phase Three: Vendors who package our code into their operating systems, appliances, and products, receive an email notice of the disclosure 24 hours before planned release of the public disclosure and link to where code will be available.
- Phase Four: Public disclosure of the vulnerability, and release of patched versions of all currently supported affected code.
In the event of a Type II Security Disclosure (in the wild, or causing known problems)
- Phase One: DNSco 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 Vendors 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-2014 Internet Systems Consortium