Archived/Security vulnerability process (draft)

This is a draft of modifications to the security vulnerability response process. The current form can be found here.
A description of the changes (and revisions) is here:
Last update: 2013 April 8 (v4).
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
----
 Xen.org Security Problem Response Process
 Introduction
 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.
 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.
 Scope of this process
 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.
 Specific process
 
 We request that anyone who discovers a vulnerability in xen.org
 software reports this by email to security (at) xen (dot) org.
 (This also covers the situation where an existing published
 changeset is retrospectively found to be a security fix)
 Immediately, and in parallel:
 
 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.
 If the vulnerability is not already public, security@xen will
 negotiate with discoverer regarding embargo date and disclosure
 schedule. See below for detailed discussion.
 
 Furthermore, also in parallel:
 
 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.
 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.
 (This may rely on the other project(s) having
 documented and responsive security contact points)
 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.
 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.
 We will write a Xen advisory including information from (b)-(f)
 
 Advisory pre-release:
 This occurs only if the advisory is embargoed (ie, the problem is
 not already public):
 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.
 At this stage the advisory will be clearly marked with the embargo
 date.
 
 Advisory public release:
 At the embargo date we will publish the advisory, and push
 bugfix changesets to public revision control trees.
 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>.
 Copies will also be sent to the pre-disclosure list.
 
 Updates
 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.
 
 Post embargo transparency:
 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.
 
 
 
 Embargo and disclosure schedule 
 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. 
 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:
 
 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. 
 Two working weeks between issue of our advisory to our
	 predisclosure list and publication.
 
 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. 
 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.
 
 Pre-disclosure list 
 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.
 This includes:
 Public hosting providers;
 Large-scale organisational users of Xen;
 Vendors of Xen-based systems;
 Distributors of operating systems with Xen support.
 
 This includes both corporations and community institutions. 
 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
 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.
 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
 their own advisory
 the impact, scope, set of vulnerable systems or the nature
 of the vulnerability
 revision control commits which are a fix for the problem
 patched software (even in binary form) without prior consultation with security@xen and/or the discoverer.
 
 List members are allowed to make available to their users only the following:
 The existance of an issue
 The assigned XSA and CVE numbers
 The planned disclosure date
 
 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:
 This is a list of organisations on the pre-disclosure list
 (not email addresses or internal business groups).
 Amazon
 Citrix
 Debian
 Intel
 Linode
 Novell
 Oracle
 Rackspace
 Redhat
 SuSE
 Ubuntu
 Xen.org security response team
 Xen 3.4 stable tree maintainer
 
 
 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
 
Category:Security
Category:Xen
Category:Developers
Category:Users
Category:Development Process
Category:Transient
Category:Archived