Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

[Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>]

Having gone through the thread, I've prepared a three-part new
proposal email.

I. Deployment with Security Team Permission
II. Predisclosure list memembership
III. Information sharing
IV. Fixes which seem to have rough consensus as they were

Perhaps I should be checking the current web page out as a git tree
and preparing a patch series ?

Thanks,
Ian.


I. Deployment with Security Team Permission
===========================================

Permitting deployment during embargo seemed to have rough consensus on
the principle.  We seemed to be converging on the idea that the
Security Team should explicitly set deployment restrictions for each
set of patches.  So I suggest something like this:

  List members may deploy fixed versions during the embargo, only with
  permission from the Security Team.  The Security Team will normally
  permit such deployment, even for systems where VMs are managed or
  used by non-members of the predisclosure risk.  Permission for
  deployment, and any restrictions, will be stated in the embargoed
  advisory text.

  The Security Team will impose deployment restrictions only insofar
  as it is necessary to prevent the exposure of technicalities (for
  example, differences in behaviour) which present a significant risk
  of rediscovery of the vulnerability.  Such situations are expected
  to be rare.



II. Predisclosure list memembership
===================================

The idea of objective criteria seemed to find favour, and the general
scheme I proposed.

Lars suggested we should "test" this.  I think therefore that we
should invite a participants in this thread to write up and post
applications which we can then test against the proposed policy.  But
we should probably wait until we have rough consensus on the new
policy shape.

I have dropped the section about bad websites.  I don't think its lack
will make much difference to the way applications are processed in
practice, and I still think documenting the issue would be useful, but
it's clear that I'm not going to get consensus for it.

Changes that I have made are:
 - Applications to be made, and decisions sent, to a public mailing list
 - Explicitly say that the Security Team decide and that they have no
   discretion
 - Explicitly say that there is appeal to the project governance process
   (Lars: perhaps this should say something different or more specific?)


So as I said before, applicants should be required to:

  - Provide information on their public web pages which makes
    it clear that and why they are eligible;

  - Specifically, publicly state that and how they are using Xen
    (so that the Security Team can verify eligibility);

  - Provide a way for members of the public to responsibly report
    security problems to the applicant, just as the Xen Project does.

The Security Team should be forbidden from trying to hunt down
eligibility information etc. and should instead be mandated to reject
incomplete requests.

Specifically, I propose that the section on list membership
applications be entirely replaced with this:

  Organisations who meet the criteria should contact
  predisclosure-applications@xenproject if they wish to receive
  pre-disclosure of advisories.  That is a public mailing list.

  You must include in the e-mail:

    * The name of your organization.

    * Domain name(s) which you use to provide Xen software/services.

    * A brief description of why you fit the criteria.

    * If not all of your products/services use Xen, a list of (some
      of) your products/services (or categories thereof) which do.

    * Link(s) to current public web pages, belonging to your
      organisation, for each of following pieces of information:

      o Evidence of your status as a service/software provider:
        + If you are a public hosting provider, your public rates
          or how to get a quote
        + If you are a software provider, how your
          software can be downloaded or purchased
        + If you are an open-source project, a mailing list
          archive and/or version control repository, with
          active development

      o Evidence of your status as a user of Xen:
        + Statements about, or descriptions of, your eligible
          production services or released software, from which it is
          immediately evident that they use Xen.

      o Information about your handling of security problems:
        + Your invitation to members of the public, who discover
          security problems with your products/services, to report
          them in confidence to you;
        + Specifically, the contact information (email addresses or
          other contact instructions) which such a member of the
          public should use.

      Blog postings, conference presentations, social media pages,
      Flash presentations, videos, sites which require registration,
      anything password-protected, etc., are not acceptable.  PDFs of
      reasonable size are acceptable so long as the URL you provide is
      of a ordinary HTML page providing a link to the PDF.

      If the pages are long and/or PDFs are involved, your email
      should say which part of the pages and documents are relevant.

    * 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 regarding confidentiality during
      an embargo period.

    * The single (non-personal) email alias you wish added to the
      predisclosure list.

  Your application will be determined by the Xen Project Security
  Team, and their decision posted to the list.  The Security Team has
  no discretion to accept applications which do not provide all of the
  information required above.

  If you are dissatisfied with the Security Team's decision you may
  appeal it via the Xen Project's governance processes.



III. Information-sharing
========================

Permitting sharing of embargoed fixes amongst predisclosure list
seemed to have rough consensus in principle.  There was some
discussion about the details.  I remain convinced that my previous
proposal is correct and I think we should be able to get consensus for
it.

So I reproduce it (unchanged from my previous proposed wording):

  List members are allowed to share fixes to embargoed issues,
  analysis, etc., with the security teams of other list members.
  Technical measures must be taken to prevents non-list-member
  organisations, or unauthorised staff in list-member organisations,
  from obtaining the embargoed materials.

  The Xen Project provides the mailing list
     xen-security-issues-discuss@xxxxxxxxxxxxxxxxxxxx
  for this purpose.  List members are encouraged to use it but
  may share with other list members' security teams via other
  channels.

  The -discuss list's distribution is identical to that of the primary
  predisclosure list xen-security-issues.  Recipient organisations who
  do not wish to receive all of the traffic on -discuss should use
  recipient-side email filtering based on the provided `List-Id'.

  The -discuss list is moderated by the Xen Project Security Team.
  Announcements of private availability of fixed versions, and
  technical messages about embargoed advisories, will be approved.
  Messages dealing with policy matters will be rejected with a
  reference to the Security Team contact address and/or public Xen
  mailing lists.


IV. Fixes which seem to have rough consensus as they were
=========================================================

(Reproduced unchanged from my previous proposed wording:)

The Security Team should not be invited to give permission
specifically for the release of patched software.  I think the rider
was mistakenly merged into the final the bullet point in the list.  It
should be separated out.  Also, the predisclosure list members should
not be invited to consult the discoverer.

The note about CVE numbers should be moved into the list of
forbidden-disclosures, as a new bullet point.  So overall I would
delete that whole paragraph about CVEs (we don't need the historical
information) and adjust the end of the forbidden disclosures to read:

    ...
    * patched software (even in binary form)
    * CVE number(s)

  without prior consultation with security@xenproject.


> Service announcements to non-list-member users during embargo

We should add just below the list of bullet points of things which may
be disclosed:

  Where the list member is a service provider who intends to take
  disruptive action such as rebooting as part of deploying a fix (see
  above): the list member's communications to its users about the
  service disruption may mention that the disruption is to correct a
  security issue, and relate it to the public information about the
  issue (as listed above).


-- 

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