Jump to: navigation, search

Difference between revisions of "Vulnerability Management"

(Downstream stakeholders notification email (public issues): start attaching patches; also suggest a shorter bug url)
Line 39: Line 39:
 
==== CVE assignment ====
 
==== 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.
+
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 ====
 
==== Get assigned CVE ====

Revision as of 19:18, 15 October 2013

The OpenStack vulnerability management team (VMT) 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 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 maximum of 3 people.

Supported versions

The Vulnerability Management team provides patches fixing vulnerabilities for the two previous releases of OpenStack, in addition to the master branch (next version under development).

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 we follow.

VMTprocess.png

Reception

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").

The first steps are to confirm the sanity of the report, create a Launchpad bug if necessary, add an ossa bugtask and subscribe the project PTL for confirmation of impact and determination of affected branches. Once we confirmed that we would 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.

Patch development

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.

Patch review

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.

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 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.

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.

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 member(s) of the VMT.

Templates

Impact description ($DESCRIPTION)

Title: $TITLE
Reporter: $CREDIT
Products: $PROJECT
Affects: $AFFECTED_SUPPORTED_BRANCHES

Description:
$CREDIT reported a vulnerability in... By doing... a... may... resulting in...
Only setups.... are affected.

CVE request email

  • To: CNA
  • Subject: CVE request for vulnerability in OpenStack $PROJECT
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

Email must be GPG-signed and GPG-encrypted.

Downstream stakeholders notification email (private issues)

  • To: Downstream stakeholders
  • Subject: [pre-OSSA] Vulnerability in OpenStack $PROJECT ($CVE)
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


Proposed patches are attached, email must be GPG-signed. Use something unique and descriptive for the patch attachment file names, for example cve-2013-4183-master-havana.patch or cve-2013-4183-stable-grizzly.patch.

Downstream stakeholders notification email (public issues)

An issue can have been publicly reported or publicly fixed.

  • To: Downstream stakeholders
  • Subject: [pre-OSSA] Upcoming advisory for publicly-reported vulnerability in OpenStack $PROJECT ($CVE)

or

  • Subject: [pre-OSSA] Upcoming advisory for publicly-fixed vulnerability in OpenStack $PROJECT ($CVE)
A vulnerability was reported (or fixed) publicly in OpenStack $PROJECT
recently, and we think it warrants a security advisory to make sure everyone
is aware of it.

We obviously can't embargo anything here since the issue is public
already, but we figured you would still appreciate a day heads-up
before we publish the advisory and attract the rest of the world
attention on the issue.

$DESCRIPTION

Havana (development branch) fix:
$REVIEWLINK (patch attached)

Grizzly fix:
$REVIEWLINK (patch attached)

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

Regards,

-- 
$VMT_COORDINATOR_NAME
OpenStack Vulnerability Management Team

Proposed patches are attached, email must be GPG-signed. Use something unique and descriptive for the patch attachment file names, for example cve-2013-4183-master-havana.patch or cve-2013-4183-stable-grizzly.patch.

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)


OpenStack Security Advisory: $NUM
CVE: $CVE
Date: December 13, 2011
$DESCRIPTION

Havana (development branch) fix:
$REVIEWLINK

Grizzly fix:
$REVIEWLINK

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://bugs.launchpad.net/nova/+bug/$BUG

-- 
$VMT_COORDINATOR_NAME
OpenStack Vulnerability Management Team


  • Email must be GPG-signed.
  • $CVE must always be of the form CVE-YYYY-XXXX
  • $NUM is of the form YYYY-XX