Import Vulnerability Management article from wiki
Change-Id: I71a85e59bf56a822620b7eb052a8180698dce875
This commit is contained in:
Jeremy Stanley
parent
dd128b91d2
commit
2d68c0f0b6
@ -2,6 +2,12 @@
|
|||||||
OpenStack Security
|
OpenStack Security
|
||||||
====================
|
====================
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:hidden:
|
||||||
|
|
||||||
|
vmt-process
|
||||||
|
|
||||||
|
|
||||||
Security is a fundamental goal of the OpenStack architecture and needs to
|
Security is a fundamental goal of the OpenStack architecture and needs to
|
||||||
be addressed at all layers of the stack. Like any complex, evolving system
|
be addressed at all layers of the stack. Like any complex, evolving system
|
||||||
security has to be vigilantly pursued, and exposures eliminated. We need
|
security has to be vigilantly pursued, and exposures eliminated. We need
|
||||||
@ -74,12 +80,7 @@ Specifically, we are responsible for the following functions:
|
|||||||
community, the Team will ensure that proper credit is given to security
|
community, the Team will ensure that proper credit is given to security
|
||||||
researchers who responsibly report issues in OpenStack.
|
researchers who responsibly report issues in OpenStack.
|
||||||
|
|
||||||
.. seealso::
|
See :doc:`vmt-process` for details on our open process.
|
||||||
|
|
||||||
See the Vulnerability_Management_ page in the wiki for details on our
|
|
||||||
open process.
|
|
||||||
|
|
||||||
.. _Vulnerability_Management: https://wiki.openstack.org/wiki/Vulnerability_Management
|
|
||||||
|
|
||||||
Other Security Teams in OpenStack
|
Other Security Teams in OpenStack
|
||||||
---------------------------------
|
---------------------------------
|
||||||
|
|||||||
BIN
doc/source/vmt-process.png
Normal file
BIN
doc/source/vmt-process.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
430
doc/source/vmt-process.rst
Normal file
430
doc/source/vmt-process.rst
Normal file
@ -0,0 +1,430 @@
|
|||||||
|
.. :Copyright: 2015, OpenStack Vulnerability Management Team
|
||||||
|
.. :License: This work is licensed under a Creative Commons
|
||||||
|
Attribution 3.0 Unported License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
==================================
|
||||||
|
Vulnerability Management Process
|
||||||
|
==================================
|
||||||
|
|
||||||
|
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 small number of people.
|
||||||
|
|
||||||
|
.. _VMT: https://launchpad.net/~openstack-vuln-mgmt
|
||||||
|
|
||||||
|
Supported versions
|
||||||
|
------------------
|
||||||
|
|
||||||
|
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`_.
|
||||||
|
|
||||||
|
.. _security supported projects: https://wiki.openstack.org/wiki/Security_supported_projects
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
.. image:: vmt-process.png
|
||||||
|
:width: 100 %
|
||||||
|
:alt: VMT Process
|
||||||
|
:target: _images/vmt-process.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"). 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.
|
||||||
|
|
||||||
|
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 `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.
|
||||||
|
|
||||||
|
.. _Vulnerability Management Liaison: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management
|
||||||
|
|
||||||
|
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, 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.
|
||||||
|
|
||||||
|
+----------+-----------+-------------------------------------------+
|
||||||
|
| 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 | Not considered a practical vulnerability |
|
||||||
|
| | OSSN | (but some people might assign a CVE for |
|
||||||
|
| | | it) |
|
||||||
|
+----------+-----------+-------------------------------------------+
|
||||||
|
| Class C2 | Potential | A vulnerability, but not in OpenStack |
|
||||||
|
| | OSSN | supported code, e.g., in a dependency |
|
||||||
|
+----------+-----------+-------------------------------------------+
|
||||||
|
| Class D | Potential | Not a vulnerability, just a bug with |
|
||||||
|
| | OSSN | (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 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)
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
The AFFECTED_VERSIONS should read like this, while both grizzly and
|
||||||
|
havana still will have point releases:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
Affects: 2011.2 versions through 2013.1.2, and 2013.2 versions through 2013.2.1
|
||||||
|
|
||||||
|
Once the last Grizzly point release is released, that line becomes:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
Affects: 2011.2 versions through 2013.2.1
|
||||||
|
|
||||||
|
If the oldest version affected is not easily identified, leave it
|
||||||
|
open-ended:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
Affects: versions through 2013.2.1
|
||||||
|
|
||||||
|
CVE Request Email (Private Issues)
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
* *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.
|
||||||
|
|
||||||
|
CVE Request Email (Public Issues)
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
* *To:* oss-security@lists.openwall.com
|
||||||
|
* *Cc:* cve-assign@mitre.org
|
||||||
|
* *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 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
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
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``.
|
||||||
|
|
||||||
|
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:
|
||||||
|
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
|
||||||
|
|
||||||
|
* Email must be GPG-signed.
|
||||||
|
* $CVE must always be of the form CVE-YYYY-XXXX
|
||||||
|
* $NUM is of the form YYYY-XX
|
||||||
Loading…
x
Reference in New Issue
Block a user