gistfile1.html

<h1>Xen.org Security Problem Response Process</h1>
    <h2>Introduction</h2>
    <p>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.</p>
    <p>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.</p>

    <h2>Scope of this process</h2>
    <p>This process primarily covers the <a href="http://www.xen.org/products/xenhyp.html">Xen Hypervisor Project</a>. Vulnerabilties reported against other Xen.org projects will be handled on a best effort basis by the relevant Project Lead together with the security team.</p>

    <h2>Specific process</h2>
    <ol type="1">
    <li><p>We request that anyone who discovers a vulnerability in xen.org
        software reports this by email to security (at) xen (dot) org.</p>
        <p>(This also covers the situation where an existing published
        changeset is retrospectively found to be a security fix)</p></li>
    <li><p>Immediately, and in parallel:</p></li>
    <ol type="a">
       <li><p>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.</p></li>
       <li><p>If the vulnerability is not already public, security@xen will
       negotiate with discoverer regarding embargo date and disclosure
       schedule. See below for detailed discussion.</p></li>
    </ol>
    <li>Furthermore, also in parallel:</li>
    <ol type="a" start="3">
    <li><p>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.</p></li>
    <li><p>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.</p></li>
       <p>(This may rely on the other project(s) having
       documented and responsive security contact points)</p>
    <li><p>We will prepare or check patch(es) which fix the
       vulnerability.  This would ideally include all relevant
       backports.  Patches will be tightly targeted on fixing the
       specific security vulnerability in the smallest, simplest and
       most reliable way.  Where necessary domain specific experts
       within the community will be brought in to help with patch
       preparation.</p></li>
    <li><p>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.</p></li>
    <li><p>We will write a Xen advisory including information from (b)-(f)</p></li>
    </ol>

    <li><p><b>Advisory pre-release:</b></p>
    <p>This occurs only if the advisory is embargoed (ie, the problem is
       not already public):</p>
    <p>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.</p>
    <p>At this stage the advisory will be clearly marked with the embargo
       date.</p>
    </li>

    <li><p><b>Advisory public release:</b></p>
    <p>At the embargo date we will publish the advisory, and push
       bugfix changesets to public revision control trees.</p>
    <p>Public advisories will be posted to xen-devel,
       xen-users and xen-annnounce and will be added to the
       <a href="http://wiki.xen.org/wiki/Security_Announcements">Security Announcements wiki page</a>.</p>
    <p>Copies will also be sent to the pre-disclosure list.</p>
    </li>

    <li><p><b>Updates</b></p>
    <p>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.</p>
    </li>

    <li><p><b>Post embargo transparency:</b></p>
    <p>During an embargo period the Xen.org security response team may
    be required to make potentially controverial decisions in private,
    since they cannot confer with the community without breaking the
    embargo. The security team will attempt to make such decisions
    following the guidance of this document and where necessary their
    own best judgement. Following the embargo period any such
    decisions will be disclosed to the community in the interests of
    transparency and to help provide guidance should a similar
    decision be required in the future.</p>
    </li>
    </ol>
    
    <h2>Embargo and disclosure schedule</h2>    
    <p>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.</p> 
    <p>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:</p>
    <ol type="1">    
    <li><p>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.</p></li>    
    <li><p>Two working weeks between issue of our advisory to our
	 predisclosure list and publication.</p></li>
    </ol>
    <p>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.</p>    
    <p>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.</p>
    
    <h2>Pre-disclosure list</h2>        
    <p>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.</p>
    <p>This includes:<ul>
      <li>Public hosting providers;</li>
      <li>Large-scale organisational users of Xen;</li>
      <li>Vendors of Xen-based systems;</li>
      <li>Distributors of operating systems with Xen support.</li>
    </ul></p>
    <p>This includes both corporations and community institutions.</p>    
    <p>Here "provider", "vendor", and "distributor" is meant to
      include anyone who is making a genuine service, available to the
      public, whether for a fee or gratis.  For projects providing a
      service for a fee, the rule of thumb of "genuine" is that you
      are offering services which people are purchasing.  For gratis
      projects, the rule of thumb for "genuine" is measured in terms
      of the amount of time committed to providing the service.  For
      instance, a software project which has 2-3 active developers,
      each of whom spend 3-4 hours per week doing development, is very
      likely to be accepted; whereas a project with a single developer
      who spends a few hours a month will most likey be rejected.</p>
    <p>For organizational users, a rule of thumb is that "large-scale"
      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.</p>
    <p>The list of entities on the pre-disclosure list is public. (Just the list
    of projects and organisations, not the actual email addresses.)</p>  
    <p>If there is an embargo, the pre-disclosure list will receive
    copies of the advisory and patches, with a clearly marked embargo
    date, as soon as they are available.  The pre-disclosure list will
    also receive copies of public advisories when they are first
    issued or updated.</p>
    <p>Organizations on the pre-disclosure list are expected to
    maintain the confidentiality of the vulnerability up to the
    embargo date which security@xen have agreed with the discoverer,
    and are committing to ensuring that any members/employees of that
    organisation who come into contact with confidential information
    will do so as well.</p>
    <p>Specifically, prior to the embargo date, pre-disclosure list members
    should not make available, even to their own customers and partners:<ul>
       <li>the Xen.org advisory</li>
       <li>their own advisory</li>
       <li>the impact, scope, set of vulnerable systems or the nature
       of the vulnerability</li>
       <li>revision control commits which are a fix for the problem</li>
       <li>patched software (even in binary form) without prior consultation with security@xen and/or the discoverer.</li>
    </ul></p>    
    <p>List members are allowed to make available to their users only the following:<ul>
       <li>The existance of an issue</li>
       <li>The assigned XSA and CVE numbers</li>
       <li>The planned disclosure date</li>
    </ul></p>

    <p>Organisations who meet the criteria should contact security@xen
      if they wish to receive pre-disclosure of advisories.  Please
      include in the e-mail: <ul>
	<li>The name of your organization</li>
	<li>A brief description of why you fit the criteria, along
	with evidence to support the claim</li>
	<li>A security alias e-mail address (no personal addresses --
	see below)</li>
	<li>A link to a web page with your security policy
	statement</li>
        <li>A statement to the effect that you have read this policy
          and agree to abide by the terms for inclusion in the list,
          specifically the requirements to regarding confidentiality
          during an embargo period</li>
      </ul></p>
    <p>Evidence that will be considered may include the following: <ul>
	<li>If you are a public hosting provider, a link to a web page
	  with your public rates</li>
	<li>If you are a software provider, a link to a web page where
	  your software can be downloaded or purchased</li>
	<li>If you are an open-source project, a link to a mailing
	  list archive and/or a version control repository
	  demonstrating active development</li>
	<li>A public key signed with a key which is in the PGP "strong
	set"</li>
    </ul></p>

    <p>Organizations already on the list who do not have a security
    alias or have not sent a statement that they have read this policy
    and will abide by it will be asked to do so.</p>

    <p>Organisations should not request subscription via the mailing
      list web interface, any such subscription requests will be
      rejected and ignored.</p>
    <p>A role address (such as security@example.com) should be used
      for each organisation, rather than one or more individual's
      direct email address. This helps to ensure that changes of
      personnel do not end up effectively dropping an organisation
      from the list.</p>

    
    <h3>Organizations on the pre-disclosure list:</h3>
    <p>This is a list of organisations on the pre-disclosure list
    (not email addresses or internal business groups).
    <ul><li>Amazon</li>
    <li>Citrix</li>
    <li>Debian</li>
    <li>Intel</li>
    <li>Linode</li>
    <li>Novell</li>
    <li>Oracle</li>
    <li>Rackspace</li>
    <li>Redhat</li>
    <li>SuSE</li>
    <li>Ubuntu</li>
    <li>Xen.org security response team</li>
    <li>Xen 3.4 stable tree maintainer</li>
    </ul></p>
    
    <h2>Change History</h2>
    <ul>
      <li><b>v1.4 Apr 2013:</b> Predisclosure list criteria changes</li>
      <li><b>v1.3 Aug 2012:</b> Various minor updates</li>
      <li><b>v1.2 Apr 2012:</b> Added pre-disclosure list</li>
      <li><b>v1.1 Feb 2012:</b> Added link to Security Announcements wiki page</li>
      <li><b>v1.0 Dec 2011:</b> Intial document published after review</li>
    </ul>