You''ll have seen we''ve issued a couple of formal security
advisories
recently. We''ve been trying to improve our approach to security
problems, and part of this is that we are developing a xen.org process
for handling vulnerabilities.
Our current draft process and policy document - which we''ve tried to
follow and develop for the recent advisories - is below. We''d
appreciate your comments and feedback.
Thanks,
Ian.
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.
Specific process
----------------
1. 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.)
2. Immediately, and in parallel:
(a) 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.
(b) If the vulnerability is not already public, security@xen will
negotiate with discoverer regarding embargo date and disclosure
schedule. See below for detailed discussion.
3. Furthermore, also in parallel:
(c) 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.
(d) We will prepare or check patch(es) which fix the vulnerability.
This would ideally include all relevant backports.
(e) We will determine which systems/configurations/versions are
vulnerable, and what the impact of the vulnerability is.
(f) We will write a Xen advisory including information from (b)-(e)
2. 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.
3. 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.
Copies will also be sent to the pre-disclosure list.
4. Updates
If new information or better patches become available, or we
discover mistakes, we may issue an amended (revision 2 or later)
public advisory.
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:
1. 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.
2. One working week 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:
- Large-scale hosting providers;
- Large-scale organisational users of Xen;
- Vendors of widely-deployed Xen-based systems;
- Distributors of widely-deployed 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.
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.
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
- 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.
Organisations who meet the criteria should contact security@xen if
they wish to receive pre-disclosure of advisories.
The pre-disclosure list will be used for embargoed advisories only.
Advisories for which there is no embargo period will not be sent to
the pre-disclosure list but only to xen-devel. If an advisory is
updated during the embargo period the updated version may not be sent
out again to the pre-disclosure list.
X-Mailer: VM 8.0.9 under Emacs 21.4.1 (i486-pc-linux-gnu)
FCC: ~/mail/Outbound
--text follows this line--
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel