Jump to: navigation, search

Difference between revisions of "Vulnerability Management"

(Impact description ($DESCRIPTION): clarify version wording and note how to handle unidentified oldest affected versions)
(This document has moved to security.openstack.org)
 
Line 1: Line 1:
The [https://launchpad.net/~openstack-vuln-mgmt OpenStack vulnerability management team] (VMT) is responsible for coordinating the progressive disclosure of a vulnerability.
+
__NOTOC__
 +
= [http://security.openstack.org/vmt-process.html Vulnerability Management] documentation has moved =
  
Members of the team are independent and security-minded folks who ensure that vulnerabilities are dealt with in a timely manner and that downstream stakeholders are notified in a coordinated and fair manner. Where a member of the team is employed by a downstream stakeholder, 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 small number of people.
+
to http://security.openstack.org/vmt-process.html but the entries below are retained for the benefit of older deep links, bookmarks and search engine indexing.
  
== Supported versions ==
+
==== [http://security.openstack.org/vmt-process.html#supported-versions Supported versions] ====
 
+
==== [http://security.openstack.org/vmt-process.html#process Process] ====
The Vulnerability Management team coordinates patches fixing vulnerabilities in one or two previous releases of OpenStack, in addition to the master branch (next version under development), for all [[security supported projects]].
+
==== [http://security.openstack.org/vmt-process.html#reception Reception] ====
 
+
==== [http://security.openstack.org/vmt-process.html#patch-development Patch development] ====
== Process ==
+
==== [http://security.openstack.org/vmt-process.html#patch-review Patch review] ====
 
+
==== [http://security.openstack.org/vmt-process.html#draft-impact-description Draft impact description] ====
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 we follow.
+
==== [http://security.openstack.org/vmt-process.html#review-impact-description Review impact description] ====
 
+
==== [http://security.openstack.org/vmt-process.html#cve-assignment CVE assignment] ====
[[File:VMTprocess.png]]
+
==== [http://security.openstack.org/vmt-process.html#get-assigned-cve Get assigned CVE] ====
 
+
==== [http://security.openstack.org/vmt-process.html#embargoed-disclosure Embargoed disclosure] ====
==== Reception ====
+
==== [http://security.openstack.org/vmt-process.html#open-bug-push-patches Open bug, push patches] ====
 
+
==== [http://security.openstack.org/vmt-process.html#publish-ossa Publish OSSA] ====
A report can be received either as a private encrypted email to one of the VMT members, or as a Launchpad security bug (check the box marked "this is a security issue"). Reports received in private should have their bug description prefaced by an embargo reminder which can be removed once the bug is switched to a public state.
+
==== [http://security.openstack.org/vmt-process.html#incident-report-taxonomy Incident report taxonomy] ====
 
+
==== [http://security.openstack.org/vmt-process.html#extent-of-disclosure Extent of disclosure] ====
The first steps are to confirm the validity of the report, create a Launchpad bug if necessary, add an ossa bugtask and subscribe the project's core security review team or [[CrossProjectLiaisons#Vulnerability_management|Vulnerability Management Liaison]] for confirmation of impact and determination of affected branches. Reports starting with an "Incomplete" ossa bugtask should have a corresponding incomplete reception message added in a comment. Once we confirm that we will issue an OSSA for it, switch the ossa bugtask status to ''Confirmed''. If the need for an OSSA is challenged, the ossa bugtask status should be set to ''Incomplete'' until that question is resolved.
+
==== [http://security.openstack.org/vmt-process.html#downstream-stakeholders Downstream stakeholders] ====
 
+
==== [http://security.openstack.org/vmt-process.html#templates Templates] ====
==== Patch development ====
+
==== [http://security.openstack.org/vmt-process.html#reception-incomplete-message-unconfirmed-issues Reception Incomplete Message (unconfirmed issues)] ====
 
+
==== [http://security.openstack.org/vmt-process.html#reception-embargo-reminder-private-issues Reception Embargo Reminder (private issues)] ====
The reporter, or the PTL, or any person that the PTL deems necessary to develop the fix is added to the security bug subscription list. A fix is proposed as a patch to the current master branch (as well as any affected supported branches) and attached to the bug.
+
==== [http://security.openstack.org/vmt-process.html#impact-description-description Impact description ($DESCRIPTION)] ====
 
+
==== [http://security.openstack.org/vmt-process.html#cve-request-email-private-issues CVE request email (private issues)] ====
==== Patch review ====
+
==== [http://security.openstack.org/vmt-process.html#cve-request-email-public-issues CVE request email (public issues)] ====
 
+
==== [http://security.openstack.org/vmt-process.html#downstream-stakeholders-notification-email-private-issues Downstream stakeholders notification email (private issues)] ====
Once the initial patch has been posted, core developers of the project are added to the bug subscription list so that the proposed patch can be pre-approved for merging. Patches need to be pre-approved so that they can be fast-tracked through review at disclosure time.
+
==== [http://security.openstack.org/vmt-process.html#openstack-security-advisories OpenStack Security Advisories] ====
 
 
==== Draft impact description ====
 
 
 
In the mean time, the VMT coordinator prepares a vulnerability description that will be communicated to downstream stakeholders, and will serve as the basis for the Security Advisory that will be finally published.
 
 
 
The description should properly credit the reporter, specify affected versions (including unsupported ones) and accurately describe impact and mitigation mechanisms. The VMT coordinator should use the template below. Once the description is posted, the ossa bugtask status should be switched to ''Triaged''.
 
 
 
==== Review impact description ====
 
 
 
The description is validated by the reporter and the PTL.
 
 
 
==== CVE assignment ====
 
 
 
To ensure full traceability, we get a CVE assigned before the issue is communicated to a larger public. This is generally done as the patch gets nearer to final approval. The ossa bugtask status is set to ''In progress'' and the approved description is sent to a CNA in an encrypted+signed email in order to get a CVE assigned. If the issue is already public, the CVE request should be sent to the oss-security list instead, including links to public bugs.
 
 
 
==== Get assigned CVE ====
 
 
 
The CNA returns the assigned CVE. It is added to the Launchpad bug (see "link to CVE" at the top-right), and the bug is retitled to "$TITLE ($CVE)".
 
 
 
==== Embargoed disclosure ====
 
 
 
Once the patches are approved and the CVE is assigned, a signed email with the vulnerability description is sent to the downstream stakeholders. The disclosure date is set to 3-5 business days, excluding Monday/Friday and holiday periods, at 1500 UTC. No stakeholder is supposed to deploy public patches before disclosure date.
 
 
 
Once the email is sent, the ossa bugtask status should be set to ''Fix committed''. At that point we can also add downstream stakeholders to the Launchpad bug, if they use Launchpad for security patches. This means adding  ~canonical-security to the bug subscribers.
 
 
 
For non-embargoed, public vulnerabilities no separate downstream advance notification is sent. Instead the OSSA bugtask is set to fix committed status once the CVE assignment is received OSSA is drafting begins immediately.
 
 
 
==== Open bug, push patches ====
 
 
 
In preparation for this, make sure you have a core developer and a stable maintainer available to help pushing the fix at disclosure time.
 
 
 
On the disclosure hour, push patches to Gerrit for review on master and supported stable branches, open bug, fast-track approvals (referencing the bug).
 
 
 
==== Publish OSSA ====
 
 
 
Shortly after pushing the patches (potentially waiting for the first test runs to complete), publish the advisory to the OpenStack ML. Wait until all patches merged to supported branches before setting the ossa bugtask status to ''Fix released''.
 
 
 
== Incident report taxonomy ==
 
 
 
The VMT is now using this classification list in order to assist vulnerability report triage, especially whenever a bug does not warrant an advisory.
 
 
{| class="wikitable"
 
|-
 
! Classes !! Outcome !! Description
 
|-
 
| Class A  || OSSA || A vulnerability to be fixed in master and all supported releases.
 
|-
 
| Class B1 || OSSN || A vulnerability that can only be fixed in master, security note for stable branches, e.g., default config value is insecure
 
|-
 
| Class B2 || OSSN || A vulnerability without a complete fix yet, security note for all versions, e.g., poor architecture / design
 
|-
 
| Class C1 || Potential OSSN || Not considered a practical vulnerability (but some people might assign a CVE for it)
 
|-
 
| Class C2 || Potential OSSN || A vulnerability, but not in OpenStack supported code, e.g., in a dependency
 
|-
 
| Class D || Potential OSSN || Not a vulnerability, just a bug with (some) security implications, e.g., strengthening opportunities
 
|-
 
| Class E ||  || Not a vulnerability at all
 
|-
 
| Class Y ||  || Vulnerability only found in development release
 
|-
 
| Class Z ||  || When due process fails
 
|}
 
 
 
== Extent of disclosure ==
 
 
 
The science of vulnerability management is somewhere around being able to assess impact and severity of a report, being able to design security patches, being an obsessive process-following perfectionist and respecting the rule of lesser disclosure.
 
 
 
Lesser disclosure is about disclosing the vulnerability details to an increasing number of people over time, but only to the people that are necessary to reach the next step. The diagram above shows "disclosure extent" across the various steps of the process.
 
 
 
Vulnerability reporters retain final control over the disclosure of their findings. If for some reason they are uncomfortable with our process, their choice of disclosure terms prevails.
 
 
 
=== Downstream stakeholders ===
 
 
 
OpenStack as an upstream project is used in a number of distributions, products, private and public service offerings that are negatively affected by vulnerabilities. In the spirit of responsible disclosure, this ecosystem, collectively known as the downstream stakeholders, needs to be warned in advance to be able to prepare patches and roll them out in a coordinated fashion on disclosure day. The embargo period is kept voluntarily small (3-5 business days), as a middle ground between keeping the vulnerability under cover for too long and not giving a chance to downstream stakeholders to react.
 
 
 
If you're currently not a referenced stakeholder and think you should definitely be included on that email distribution list, please submit an email with a rationale to [https://launchpad.net/~openstack-vuln-mgmt/+members member(s) of the VMT].
 
 
 
== Templates ==
 
 
 
=== Reception Incomplete Message (unconfirmed issues) ===
 
 
 
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.
 
 
 
=== Reception Embargo Reminder (private issues) ===
 
 
 
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments.
 
 
 
=== Impact description ($DESCRIPTION) ===
 
 
 
<pre><nowiki>
 
Title: $TITLE
 
Reporter: $CREDIT
 
Products: $PROJECT
 
Affects: $AFFECTED_VERSIONS
 
 
 
Description:
 
$CREDIT reported a vulnerability in... By doing... a... may... resulting in...
 
Only setups.... are affected.
 
</nowiki></pre>
 
 
 
The AFFECTED_VERSIONS should read like this, while both grizzly and havana still will have point releases:
 
<pre>Affects: 2011.2 versions through 2013.1.2, and 2013.2 versions through 2013.2.1</pre>
 
Once the last Grizzly point release is released, that line becomes:
 
<pre>Affects: 2011.2 versions through 2013.2.1</pre>
 
 
 
If the oldest version affected is not easily identified, leave it open-ended:
 
 
 
<pre>Affects: versions through 2013.2.1</pre>
 
 
 
=== CVE request email (private issues) ===
 
 
 
* ''To:'' CNA
 
* ''Subject:'' CVE request for vulnerability in OpenStack $PROJECT
 
 
 
<pre><nowiki>
 
A vulnerability was discovered in OpenStack (see below). In order to
 
ensure full traceability, we need a CVE number assigned that we can
 
attach to private and public notifications. Please treat the
 
following information as confidential until further public
 
disclosure.
 
 
 
$DESCRIPTION
 
 
 
Thanks in advance,
 
 
 
--  
 
$VMT_COORDINATOR_NAME
 
OpenStack Vulnerability Management Team
 
</nowiki></pre>
 
 
 
Email must be GPG-signed and GPG-encrypted.
 
 
 
=== CVE request email (public issues) ===
 
 
 
* ''To:'' oss-security@lists.openwall.com
 
* ''Cc:'' cve-assign@mitre.org
 
* ''Subject:'' CVE request for vulnerability in OpenStack $PROJECT
 
 
 
<pre><nowiki>
 
A vulnerability was discovered in OpenStack (see below). In order to
 
ensure full traceability, we need a CVE number assigned that we can
 
attach to further notifications. This issue is already public, although an
 
advisory was not sent yet.
 
 
 
$DESCRIPTION
 
 
 
References:
 
https://launchpad.net/bugs/$BUG
 
 
 
Thanks in advance,
 
 
 
--  
 
$VMT_COORDINATOR_NAME
 
OpenStack Vulnerability Management Team
 
</nowiki></pre>
 
 
 
Email must be GPG-signed but not encrypted.
 
 
 
=== Downstream stakeholders notification email (private issues) ===
 
 
 
* ''To:'' Downstream stakeholders
 
* ''Subject:'' [pre-OSSA] Vulnerability in OpenStack $PROJECT ($CVE)
 
 
 
<pre><nowiki>
 
This is an advance warning of a vulnerability discovered in OpenStack,
 
to give you, as downstream stakeholders, a chance to coordinate the
 
release of fixes and reduce the vulnerability window. Please treat the
 
following information as confidential until the proposed public
 
disclosure date.
 
 
 
$DESCRIPTION
 
 
 
Proposed patch:
 
See attached patches. Unless a flaw is discovered in them, these patches
 
will be merged to $BRANCHES on the public disclosure date.
 
 
 
CVE: $CVE
 
 
 
Proposed public disclosure date/time:
 
$DISCLOSURE, 1500UTC
 
Please do not make the issue public (or release public patches) before
 
this coordinated embargo date.
 
 
 
Regards,
 
 
 
--
 
$VMT_COORDINATOR_NAME
 
OpenStack Vulnerability Management Team
 
</nowiki></pre>
 
 
 
 
 
Proposed patches are attached, email must be GPG-signed. Use something unique and descriptive for the patch attachment file names, for example <code>cve-2013-4183-master-havana.patch</code> or <code>cve-2013-4183-stable-grizzly.patch</code>.
 
 
 
=== OpenStack Security Advisories ===
 
 
 
We send two separate emails, to avoid off-topic replies to oss-security list:
 
* ''To:'' openstack-announce@lists.openstack.org, openstack@lists.openstack.org
 
* ''To:'' oss-security@lists.openwall.com
 
 
 
 
 
Subject and content for both emails is identical:
 
* ''Subject:'' [OSSA $NUM] $TITLE ($CVE)
 
 
 
 
 
<pre><nowiki>
 
OpenStack Security Advisory: $NUM
 
CVE: $CVE
 
Date: December 13, 2011
 
$DESCRIPTION
 
 
 
Havana (development branch) fix:
 
https://review.openstack.org/$MASTER_REVIEW
 
 
 
Grizzly fix:
 
https://review.openstack.org/$STABLE_REVIEW
 
 
 
Notes:
 
This fix will be included in the $MILESTONE development milestone and in
 
a future $NEXTSTABLE release.
 
 
 
References:
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=$CVE
 
https://launchpad.net/bugs/$BUG
 
 
 
--  
 
$VMT_COORDINATOR_NAME
 
OpenStack Vulnerability Management Team
 
</nowiki></pre>
 
 
 
 
 
* Email must be GPG-signed.
 
* $CVE must always be of the form CVE-YYYY-XXXX
 
* $NUM is of the form YYYY-XX
 

Latest revision as of 15:49, 14 April 2015

Vulnerability Management documentation has moved

to http://security.openstack.org/vmt-process.html but the entries below are retained for the benefit of older deep links, bookmarks and search engine indexing.

Supported versions

Process

Reception

Patch development

Patch review

Draft impact description

Review impact description

CVE assignment

Get assigned CVE

Embargoed disclosure

Open bug, push patches

Publish OSSA

Incident report taxonomy

Extent of disclosure

Downstream stakeholders

Templates

Reception Incomplete Message (unconfirmed issues)

Reception Embargo Reminder (private issues)

Impact description ($DESCRIPTION)

CVE request email (private issues)

CVE request email (public issues)

Downstream stakeholders notification email (private issues)

OpenStack Security Advisories