<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
-<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<meta http-equiv="Content-Type" content="text/html" />
<title>Xen.org Security Problem Response Process</title>
<meta name="description" content="Xen.org, home of the Xen® hypervisor, the powerful open source industry standard for virtualization.">
<meta name="keywords" content="xen 2.0, xen 3.0, hypervisor, server consolidation, open source, ian pratt, virtualization, virtualisation, xen, xensource, security, vulnerability, process">
</script>
<script type="text/javascript" src="/globals/menu_data_xenorg_main.js"></script>
- <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
+ <meta http-equiv="Content-Type" content="text/html">
<link rel="shortcut icon" href="/favicon.ico">
</head>
addresses (ideally, role addresses) of the security response teams for
significant Xen operators and distributors.</p>
<p>This includes:<ul>
- <li>Large-scale hosting providers;</li>
+ <li>Public hosting providers;</li>
<li>Large-scale organisational users of Xen;</li>
- <li>Vendors of widely-deployed Xen-based systems;</li>
- <li>Distributors of widely-deployed operating systems with Xen support.</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 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.</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
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>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.</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>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. Organisations should not request subscription via the mailing list web interface, any such subscription requests will be rejected and ignored.</p>
- <p>Normally we would prefer that a role address 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>
+ <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>
<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>
-
+
</td>
<td width="10"></td>
- </tr>
+ </tr>
</table>
<!-- end callout -->
projects / people / iwj / security-process.git / commitdiff