Jump to: navigation, search

Difference between revisions of "Vulnerability Management"

m
(This document has moved to security.openstack.org)
 
(40 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
== Team ==
+
= [http://security.openstack.org/vmt-process.html Vulnerability Management] documentation has moved =
The [https://launchpad.net/~openstack-vuln-mgmt 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.
+
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.
  
== Support ==
+
==== [http://security.openstack.org/vmt-process.html#supported-versions Supported versions] ====
 
+
==== [http://security.openstack.org/vmt-process.html#process Process] ====
The Vulnerability Management team provides patches fixing vulnerabilities for the two previous releases of OpenStack. It will synchronize advisory publication with the landing of patches on the current development and current stable release branches.
+
==== [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] ====
==== Reception ====
+
==== [http://security.openstack.org/vmt-process.html#get-assigned-cve Get assigned CVE] ====
 
+
==== [http://security.openstack.org/vmt-process.html#embargoed-disclosure Embargoed disclosure] ====
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".
+
==== [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] ====
The first steps are to confirm the sanity of the report, create a Launchpad bug, and subscribe the project PTL for confirmation of impact.
+
==== [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] ====
==== Fix development and approval ====
+
==== [http://security.openstack.org/vmt-process.html#downstream-stakeholders Downstream stakeholders] ====
 
+
==== [http://security.openstack.org/vmt-process.html#templates Templates] ====
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 and attached to the bug.
+
==== [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)] ====
Once that's done, 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#impact-description-description Impact description ($DESCRIPTION)] ====
 
+
==== [http://security.openstack.org/vmt-process.html#cve-request-email-private-issues CVE request email (private issues)] ====
==== Vulnerability description ====
+
==== [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)] ====
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.
+
==== [http://security.openstack.org/vmt-process.html#openstack-security-advisories OpenStack Security Advisories] ====
 
 
The description should properly credit the reporter and accurately describe impact and mitigation mechanisms. The description is validated by the reporter and the PTL.
 
 
 
==== Downstream stakeholders warning, CVE assignment ====
 
 
 
Once the fix and the description are approved, an email with the vulnerability description is sent to the downstream stakeholders. A CVE is assigned to the vulnerability by one of the stakeholders which happens to also be a CNA. 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.
 
 
 
==== Disclosure preparation ====
 
 
 
Make sure you have a core developer and a stable maintainer available to push the fix at disclosure time.
 
 
 
==== Disclosure ====
 
 
 
On the disclosure hour, push patch to Gerrit for review on master and supported stable branches, open bug, fast-track approvals (referencing the bug). Once the merge for master and the current stable release hits, publish the advisory to the OpenStack ML.
 
 
 
== 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. here is a map of how the vulnerability will be disclosed:
 
 
 
* Receive encrypted email from original reporter: ''Reporter, Coordinator''
 
* Create security-restricted Launchpad bug entry: ''Reporter, vuln-mgmt team''
 
* Warn PTL of affected project to confirm impact: ''Reporter, vuln-mgmt team, PTL''
 
* Develop fix: ''Reporter, vuln-mgmt team, PTL + key devs''
 
* Get fix pre-approved by Core team: ''Reporter, vuln-mgmt team, core devs''
 
* Send issue/fix to downstream stakeholders, get CVE: ''Reporter, vuln-mgmt team, core devs, downstream stakeholders''
 
* Push fix to Gerrit, open bug: ''World (active)''
 
* Issue advisory: ''World (passive)''
 
 
 
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].
 
 
 
== Classification ==
 
Each incoming vulnerability will be classified into one of three categories, each triggering a different workflow.
 
 
 
{| border="1" cellpadding="2" cellspacing="0"
 
|<#eeeeee>| Level
 
|<#eeeeee>| 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
 
|}
 
 
 
== Template for impact description ($DESCRIPTION) ==
 
 
 
 
 
<pre><nowiki>
 
Title: $TITLE
 
Impact: Critical|High|Medium|Low
 
Reporter: $CREDIT
 
Products: $PROJECT
 
Affects: All versions
 
 
 
Description:
 
$CREDIT reported a vulnerability in... By doing... a... may... resulting in...
 
Only setups.... are affected.
 
</nowiki></pre>
 
 
 
 
 
== Template for vulnerability description email ==
 
 
 
* ''To:'' Downstream stakeholders
 
* ''Subject:'' Vulnerability in OpenStack $PROJECT
 
 
 
 
 
<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 diff. This proposed patch will be merged to Nova master and
 
stable/diablo branches on public disclosure date.
 
 
 
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 patch is attached, email must be GPG-signed.
 
 
 
== Template for OpenStack Security Advisories ==
 
 
 
* ''To:'' openstack@lists.launchpad.net, oss-security@lists.openwall.com
 
* ''Subject:'' [OSSA $NUM] $TITLE ($CVE)
 
 
 
 
 
<pre><nowiki>
 
OpenStack Security Advisory: $NUM
 
CVE: $CVE
 
Date: December 13, 2011
 
$DESCRIPTION
 
 
 
Fixes:
 
Folsom: $GITHUB_MASTER_COMMIT
 
2012.1: $GITHUB_ESSEX_COMMIT
 
2011.3: $GITHUB_DIABLO_COMMIT
 
 
 
References:
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=$CVE
 
https://bugs.launchpad.net/nova/+bug/$BUG
 
 
 
Notes:
 
This fix will be included in the $MILESTONE development milestone and in
 
a future $NEXTSTABLE release.
 
 
 
--  
 
$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