Re: [Xen-devel] [PATCH RFC] Make all public hosting providers eligible for the pre-disclosure list

[Joseph Glanville <joseph.glanville@xxxxxxxxxxxxxx>]

Hi,

Firstly I would like to say that it's great this conversation is
happening on the open list and that a wider set of organisations are
being considered.

On 16 November 2012 04:14, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> As discussed on the xen-devel mailing list, allow any public hosting
> provider to join the pre-disclosure list:
> * Change "Large hosting providers" to "Public hosting providers"
> * Add rule of thumb for what "public hosting provider" means
> * Add an itemized list of information to be included in the application,
> to make expectations clear and (hopefully) applications more streamlined.

As a smaller but more specialized hosting provider (security concious
clientèle) I am really glad to hear this.

I think important information that should be forthcoming from service
providers wanting to join the pre-disclosure group would be:

a) How they consume Xen, be it via a vendor, distro packages of some
kind or whether they build and package their own. Those doing their
own packaging I feel should be given somewhat of a priority because
they aren't able to rely on their vendor and instead must dedicate
resources to responding.
b) Their upgrade and security response procedures. It doesn't make
sense for someone to be on the pre-disclosure list if they lack the
ability (or more importantly the requirement) to aggressively test and
push out security fixes.
c) Resources available to assist in testing security patches. This
might be a non-issue but I personally think it's somewhat important
that groups on the pre-disclosure list are able to assist in testing
or reviewing patches, this improves the quality of said patches and
might allow a greater degree of vulnerability exploration. This is
however, largely my own opinion on what is considered fair
contribution in return for the privilege.

I think there should also be appropriate "guideline" points/criteria
that should be covered by other categories of organisations seeking to
join the pre-disclosure group.

Sorry if ideas along the lines of these have already been raised.

>
> NOTE: This RFC is meant to be a way to start a discussion on the exact
> wording which will be voted on.  Once it has gone through review from
> the xen-devel mailing list, I will post an "RC" and announce it on the
> Xen blog, as well as on xen-users.  Once discussion seems to have
> converged, I will post a "FINAL" one, which I will put up for a vote.
>
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> ---
>  security_vulnerability_process.html |   27 ++++++++++++++++++++-------
>  1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/security_vulnerability_process.html 
> b/security_vulnerability_process.html
> index e305371..35236c9 100644
> --- a/security_vulnerability_process.html
> +++ b/security_vulnerability_process.html
> @@ -194,16 +194,18 @@ if(ns4)_d.write("<scr"+"ipt type=text/javascript 
> src=/globals/mmenuns4.js><\/scr
>      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>
>      </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 as a rule of thumb, "public hosting provider" means
> +    "selling virtualization services to the general public";
> +    "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>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
> @@ -229,8 +231,19 @@ if(ns4)_d.write("<scr"+"ipt type=text/javascript 
> src=/globals/mmenuns4.js><\/scr
>         <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</li>
> +       <li>A security alias e-mail address (see below)</li>
> +       <li>A web page with your security policy statement</li>
> +       <li>If you are a public hosting provider, a web page with your public 
> rates</li>
> +      </ul>
> +      Organisations should not request subscription via the mailing
> +      list web interface, any such subscription requests will be
> +      rejected and ignored.</p>
> +    <p>We 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>
>
>
>      <h3>Organizations on the pre-disclosure list:</h3>
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel