From: Ian Campbell Date: Thu, 16 Aug 2012 14:04:06 +0000 (+0100) Subject: Baseline version. X-Git-Tag: v2.7~18 X-Git-Url: http://xenbits.xensource.com/gitweb?a=commitdiff_plain;h=dc4c41fc663cfea07d4ff1e442f97732beb5b922;p=people%2Fiwj%2Fsecurity-process.git Baseline version. Downloaded from http://www.xen.org/projects/security_vulnerability_process.html at Thu Aug 16 15:04:25 BST 2012 --- dc4c41fc663cfea07d4ff1e442f97732beb5b922 diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html new file mode 100644 index 0000000..d1a6629 --- /dev/null +++ b/security_vulnerability_process.html @@ -0,0 +1,340 @@ + + + + + Xen.org Security Problem Response Process + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
  
 
+
 
Xen 		 
+ + + + + + + +
HomeProductsSupportCommunityBlog
 
Products | Downloads | Xen Hypervisor | + Xen ARM | Xen Cloud Platform | Projects | Solution Search  
 
+ + + + + + + + + + +
+ +

Xen.org Security Problem Response Process

+

Introduction

+

Computer systems have bugs. Currently recognised best practice for bugs + with security implications is to notify significant downstream users in + private; leave a reasonable interval for downstreams to respond and prepare + updated software packages; then make public disclosure.

+

We want to encourage people to report bugs they find to us. Therefore we + will treat with respect the requests of discoverers, or other vendors, who + report problems to us.

+ +

Specific process

+
    +

  1. We request that anyone who discovers a vulnerability in xen.org + software reports this by email to security (at) xen (dot) org.

    +

    (This also covers the situation where an existing published + changeset is retrospectively found to be a security fix)

    2. +

  2. Immediately, and in parallel:

    3. +
      +

    1. Those of us on the xen.org team who are aware of the problem + will notify security@xen if disclosure wasn't made there + already.

      2. +

    2. If the vulnerability is not already public, security@xen will + negotiate with discoverer regarding embargo date and disclosure + schedule. See below for detailed discussion.

      3. +
    +
  3. Furthermore, also in parallel:
    4. +
      +

    1. security@xen will check whether the discoverer, or other people + already aware of the problem, have allocated a CVE number. If + not, we will acquire a CVE candidate number ourselves, and + make sure that everyone who is aware of the problem is also + aware of the CVE number.

      2. +

    2. If we think other software systems (for example, competing + hypervisor systems) are likely to be affected by the same + vulnerability, we will try to make those other projects aware + of the problem and include them in the advisory preparation + process.

      3. +

      (This may rely on the other project(s) having + documented and responsive security contact points)

      +

    3. We will prepare or check patch(es) which fix the vulnerability. + This would ideally include all relevant backports.

      4. +

    4. We will determine which systems/configurations/versions are + vulnerable, and what the impact of the vulnerability is. + Depending on the nature of the vulnerability this may involve + sharing information about the vulnerability (in confidence, if + the issue is embargoed) with hardware vendors and/or other + software projects.

      5. +

    5. We will write a Xen advisory including information from (b)-(f)

      6. +
    + +

  4. Advisory pre-release:

    +

    This occurs only if the advisory is embargoed (ie, the problem is + not already public):

    +

    As soon as our advisory is available, we will send it, + including patches, to members of the Xen security pre-disclosure + list. For more information about this list, see below.

    +

    At this stage the advisory will be clearly marked with the embargo + date.

    +
    5. + +

  5. Advisory public release:

    +

    At the embargo date we will publish the advisory, and push + bugfix changesets to public revision control trees.

    +

    Public advisories will be posted to xen-devel, + xen-users and xen-annnounce and will be added to the + Security Announcements wiki page.

    +

    Copies will also be sent to the pre-disclosure list, unless + the advisory was already sent there previously during the embargo + period and has not been updated since.

    +
    6. + +

  6. Updates

    +

    If new information or better patches become available, or we + discover mistakes, we may issue an amended (revision 2 or later) + public advisory. This will also be sent to the pre-disclosure + list.

    +
    7. +
+ +

Embargo and disclosure schedule

+

If a vulnerability is not already public, we would like to notify + significant distributors and operators of Xen so that they can prepare + patched software in advance. This will help minimise the degree to which + there are Xen users who are vulnerable but can't get patches.

+

As discussed, we will negotiate with discoverers about disclosure + schedule. Our usual starting point for that negotiation, unless there are + reasons to diverge from this, would be:

+
    +

  1. One working week between notification arriving at security@xen + and the issue of our own advisory to our predisclosure list. We + will use this time to gather information and prepare our + advisory, including required patches.

    2. +

  2. Two working weeks between issue of our advisory to our + predisclosure list and publication.

    3. +
+

When a discoverer reports a problem to us and requests longer delays than + we would consider ideal, we will honour such a request if reasonable. If a + discoverer wants an accelerated disclosure compared to what we would prefer, + we naturally do not have the power to insist that a discoverer waits for us + to be ready and will honour the date specified by the discoverer.

+

Naturally, if a vulnerability is being exploited in the wild we will make + immediately public release of the advisory and patch(es) and expect others + to do likewise.

+ +

Pre-disclosure list

+

Xen.org operates a pre-disclosure list. This list contains the email + addresses (ideally, role addresses) of the security response teams for + significant Xen operators and distributors.

+

This includes:

    +
  • Large-scale hosting providers;
    • +
  • Large-scale organisational users of Xen;
    • +
  • Vendors of widely-deployed Xen-based systems;
    • +
  • Distributors of widely-deployed operating systems with Xen support.
    • +

+

This includes both corporations and community institutions.

+

Here as a rule of thumb "large scale" and "widely deployed" means an + installed base of 300,000 or more Xen guests; other well-established + organisations with a mature security response process will be considered on + a case-by-case basis.

+

The list of entities on the pre-disclosure list is public. (Just the list + of projects and organisations, not the actual email addresses.)

+

Pre-disclosure list members are expected to maintain the confidentiality + of the vulnerability up to the embargo date which security@xen have agreed + with the discoverer.

+

Specifically, prior to the embargo date, pre-disclosure list members + should not make available, even to their own customers and partners:

    +
  • the Xen.org advisory
    • +
  • their own advisory
    • +
  • revision control commits which are a fix for the problem
    • +
  • patched software (even in binary form) without prior consultation with security@xen and/or the discoverer.
    • +

+

Organisations who meet the criteria should contact security@xen if they wish to receive pre-disclosure of advisories.

+

The pre-disclosure list will also receive copies of public advisories when they are first issued or updated.

+ +

Organizations on the pre-disclosure list:

+

This is a list of organisations on the pre-disclosure list + (not email addresses or internal business groups). +

  • Amazon
    • +
  • Citrix
    • +
  • Debian
    • +
  • Intel
    • +
  • Linode
    • +
  • Novell
    • +
  • Oracle
    • +
  • Rackspace
    • +
  • Redhat
    • +
  • SuSE
    • +
  • Ubuntu
    • +
  • Xen.org security response team
    • +
  • Xen 3.4 stable tree maintainer
    • +

+ +

Change History

+
    +
  • v1.2 Apr 2012: Added pre-disclosure list
    • +
  • v1.1 Feb 2012: Added link to Security Announcements wiki page
    • +
  • v1.0 Dec 2011: Intial document published after review
    • +
+ +
+ + + 		 
  
+ + + + + + + + +
+ + + + + + + + + + + + + +
  +

News:
+ Press Releases
+ Blog

+ 		 

Resources:
+ Wiki
+ Sources
+ Downloads
+ Governance
+ Security Information

+ 		 

Connect:
+ Mailing Lists
+ Search Mailing Lists
+ IRC
+ Twitter
+ LinkedIn

+ 		 

Miscellaneous:
+ Contact us
+ Legal and Privacy
+ Trademark and Logos
+ Merchandise
+ Jobs in the Community

+ 		 
+
  
+ + + + + + + +
+

Copyright + +
+ Citrix Systems, Inc. All rights reserved.

+ 		Citrix
+ + + + +
+ + + + + +
Rackspace +

Xen.org's servers are hosted with RackSpace, monitoring our
+ servers 24x7x365 and backed by RackSpace's Fanatical Support®.

+
+ + + + +