Difference between revisions of "Vulnerability Management"
| Line 5: | Line 5: | ||
The [https://launchpad.net/~openstack-vuln-mgmt OpenStack vulnerability management team] is responsible for coordinating the progressive disclosure of a vulnerability. | The [https://launchpad.net/~openstack-vuln-mgmt OpenStack vulnerability management team] is responsible for coordinating the progressive disclosure of a vulnerability. | ||
| − | Members of the team are independent and security-minded folks that | + | Members of the team are independent and security-minded folks who ensure that vulnerabilities are dealt with in a timely manner and that downstream users are notified in a coordinated and fair manner. Where a member of the team is employed by a downstream user, the member does not give their employer prior notice of any vulnerabilities. In order to reduce the disclosure of vulnerability in the early stages, membership of this team is intentionally limited to a maximum of 3 people. |
== Classification == | == Classification == | ||
Revision as of 07:20, 25 November 2011
Vulnerability Management
Team
The OpenStack vulnerability management team is responsible for coordinating the progressive disclosure of a vulnerability.
Members of the team are independent and security-minded folks who ensure that vulnerabilities are dealt with in a timely manner and that downstream users are notified in a coordinated and fair manner. Where a member of the team is employed by a downstream user, the member does not give their employer prior notice of any vulnerabilities. In order to reduce the disclosure of vulnerability in the early stages, membership of this team is intentionally limited to a maximum of 3 people.
Classification
Each incoming vulnerability will be classified into one of three categories, each triggering a different workflow.
| Level | Description |
| Critical | Directly-exploitable vulnerability, allowing the attacker to escalate rights, take down VMs... |
| Normal | Indirect vulnerability that could result in security issue under certain circumstances. |
| Low | Non-exploitable vulnerabilities due to architectural choices that could be improved |
Process
Each security bug is assigned a VMT coordinator (member from the vulnerability management team) that will drive the fixing and disclosure process. Here are the steps to follow (depending on whether the entry comes from an encrypted mail or a Launchpad report), together with the width of disclosure at each step.
From Encrypted email
| Phase |
| Receive encrypted email from original reporter |
| Warn PTL of affected project, confirmation of impact |
| Create security-restricted Launchpad bug entry |
From Launchpad bug entry
| Phase |
| Receive bug report, assign coordinator |
| Warn PTL of affected project, confirmation of impact |
Coordinated disclosure
| Phase |
| Develop fix with original reporter, PTL (and a few other core developers if needed) |
| Get fix pre-approved by Core team |
| Communicate issue and fix to downstream users, define public disclosure date/time |
| At disclosure date: Get core developers ready, push fix to Gerrit and have them approve it |
| Distributions deploy fixes |
| Issue advisories, open bug |
