|
|
# Security Policy
|
|
|
|
|
|
## Reporting security issue
|
|
|
|
|
|
If you wish to report a possible security issue in OpenSSL please either fill an [issue](https://gitlab.isc.org/isc-projects/bind9/issues/new) and please make sure you tick the checkbox labeled "This issue is confidential and should only be visible to team members with at least Reporter access.", or by emailing to security-officer@isc.org. If you want to encrypt the email, you can use the [ISC Security Officer's Public Key](https://www.isc.org/downloads/software-support-policy/openpgp-key/).
|
|
|
|
|
|
## Issue triage
|
|
|
|
|
|
Notifications are received by the BIND Engineering Team members. We engage resources within ISC to start the investigation and prioritisation.
|
|
|
|
|
|
## Issue severity
|
|
|
|
|
|
We will determine the risk of each issue, taking into account our experience dealing with past issues, versions affected, common defaults, and use cases. We use the following severity categories:
|
|
|
|
|
|
* **CRITICAL** Severity. This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.
|
|
|
* **HIGH** Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control.
|
|
|
* **MEDIUM** Severity. This includes issues like crashes in client applications, flaws in protocols that are less commonly used, and local flaws. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.
|
|
|
* **LOW** Severity. This includes issues such as those that only affect the BIND 9 command line utility, unlikely configurations, or hard to exploit attacks. These will in general be fixed immediately in latest development versions, and may be backported to older versions that are still getting updates. We will update the vulnerabilities page and note the issue CVE in the changelog and commit message, but they may not trigger new releases.
|
|
|
|
|
|
## Prenotification policy
|
|
|
|
|
|
Where we are planning an update that fixes security issues we will use the procedure described in [ISC Software Defect and Security Vulnerability Disclosure Policy](https://kb.isc.org/article/AA-00861/0).
|
|
|
|
|
|
## Engineering Policies
|
|
|
|
|
|
This section describes the preferred ways of handling the security issues for the BIND Engineering Team.
|
|
|
|
|
|
### Issues
|
|
|
|
|
|
The GitLab issues that describes security problem in the BIND code MUST be marked as [Confidential](https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html).
|
|
|
|
|
|
This means that either the original submitter would mark the issue as confidential, or when anybody from the team finds out this might a security issue, he or she would be mark the issue as confidential.
|
|
|
|
|
|
The issue title MUST be changed to begin with [CVE-YYYY-NNNNN] when the CVE number is assigned by Security Officer or other party.
|
|
|
|
|
|
### Git Repository
|
|
|
|
|
|
The work on CRITICAL-MEDIUM priority issues MUST be commenced in a private git repository that is open only to the BIND Team members. The Merge Requests for CRITICAL-MEDIUM priority issues MUST NOT be merged until prior to the release.
|
|
|
|
|
|
### Post-release Steps
|
|
|
|
|
|
After fixed versions of BIND are released to the general public, the issue describing a security vulnerability is made public for a full disclosure. We at ISC believe that transparency is valuable in open-source projects. |
|
|
\ No newline at end of file |