From 563000758895995c4981d84614bf44885f9336bc Mon Sep 17 00:00:00 2001 From: George Dunlap Date: Thu, 15 Nov 2012 16:15:19 +0000 Subject: [PATCH] Expand eligibility for the pre-disclosure list As discussed on the xen-devel mailing list, expand eligibility of the pre-disclosure list to include any public hosting provider, as well as software project: * Change "Large hosting providers" to "Public hosting providers" * Remove "widely-deployed" from vendors and distributors * Add rules of thumb for what constitutes "genuine" * Add an itemized list of information to be included in the application, to make expectations clear and (hopefully) applications more streamlined. The first will allow hosting providers of any size to join. The second will allow software projects and vendors of any size to join. The third and fourth will help describe exactly what criteria will be used to determine eligibility for 1 and 2. Additionally, this proposal adds the following requirements: * Applicants and current members must use an e-mail alias, not an individual's e-mail * Applicants and current members must submit a statement saying that they have read, understand, and will abide by this process document. v4: - Make it clear that the organization is committing to respecting the secrecy, as well as committing to the secrecy of all members who are exposed to the information during the pre-disclosure period. v3: - Organizations already on the list also must conform to requirements for a security alias and a statement saying they're read and will abide by the policy. v2: - Include "genuine" software providers, and a rule of thumb for "genuine" - Include evidence for software providers - Allow "a key signed with a key in the PGP strong set" as evidence - Require applicants to state they have read and understand policy and will abide by it - Minor suggested clarifications - Added version message at bottom - Made security aliases a requirement Signed-off-by: George Dunlap --- security_vulnerability_process.html | 84 +++++++++++++++++++++++------ 1 file changed, 68 insertions(+), 16 deletions(-) diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html index e305371..531ceb4 100644 --- a/security_vulnerability_process.html +++ b/security_vulnerability_process.html @@ -1,7 +1,7 @@ - + Xen.org Security Problem Response Process @@ -14,7 +14,7 @@ if(ns4)_d.write("<\/scr - + @@ -194,16 +194,27 @@ if(ns4)_d.write("<\/scr addresses (ideally, role addresses) of the security response teams for significant Xen operators and distributors.

This includes:

    -
  • Large-scale hosting providers;
    • +
  • Public hosting providers;
  • Large-scale organisational users of Xen;
    • -
  • Vendors of widely-deployed Xen-based systems;
    • -
  • Distributors of widely-deployed operating systems with Xen support.
    • +
  • Vendors of Xen-based systems;
    • +
  • Distributors of 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.

+

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.

+

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.

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

If there is an embargo, the pre-disclosure list will receive @@ -211,9 +222,12 @@ if(ns4)_d.write("<\/scr 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.

-

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.

+

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.

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
    • @@ -229,8 +243,45 @@ if(ns4)_d.write("<\/scr
  • The planned disclosure date

-

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.

-

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

+

Organisations who meet the criteria should contact security@xen + if they wish to receive pre-disclosure of advisories. Please + include in the e-mail:

    +
  • The name of your organization
    • +
  • A brief description of why you fit the criteria, along + with evidence to support the claim
    • +
  • A security alias e-mail address (no personal addresses -- + see below)
    • +
  • A link to a web page with your security policy + statement
    • +
  • 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
    • +

+

Evidence that will be considered may include the following:

    +
  • If you are a public hosting provider, a link to a web page + with your public rates
    • +
  • If you are a software provider, a link to a web page where + your software can be downloaded or purchased
    • +
  • If you are an open-source project, a link to a mailing + list archive and/or a version control repository + demonstrating active development
    • +
  • A public key signed with a key which is in the PGP "strong + set"
    • +

+ +

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.

+ +

Organisations should not request subscription via the mailing + list web interface, any such subscription requests will be + rejected and ignored.

+

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.

Organizations on the pre-disclosure list:

@@ -253,15 +304,16 @@ if(ns4)_d.write("<\/scr

Change History

    +
  • v1.4 Apr 2013: Predisclosure list criteria changes
  • v1.3 Aug 2012: Various minor updates
  • 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
- + - + -- 2.39.5