From: Ian Jackson Date: Fri, 16 Jan 2015 17:31:23 +0000 (+0000) Subject: Reformat to align with web version: Remove whitespace X-Git-Url: http://xenbits.xensource.com/gitweb?a=commitdiff_plain;h=52f505c02cb75d6f175a6132c67a00abea3dc164;p=people%2Flarsk%2Fsecurity-process.git Reformat to align with web version: Remove whitespace perl -i~ -pe 's/^\s+//' security_vulnerability_process.html Signed-off-by: Ian Jackson --- diff --git a/security_vulnerability_process.html b/security_vulnerability_process.html index 531ceb4..8d9e4b7 100644 --- a/security_vulnerability_process.html +++ b/security_vulnerability_process.html @@ -2,424 +2,392 @@ - Xen.org Security Problem Response Process - - - - +Xen.org Security Problem Response Process + + + + - - - - + + - - - - - - - - - + + + + + + + + - -

+ + - - - - - - - + + + + + + - - - - - - - - - - - - - + + + + + + + + + + +

- - - - - - - -

Home

+ + + + + + + +

- - - - - - - - - - -

- -

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 Xen Hypervisor Project. 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 - Security Announcements wiki page.
-
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

- -

- - -

+ + + + + + + + +

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

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 +Security Announcements wiki page.
+
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

+ +

- - - - - - - + + + + +

- - - - - - - - - - - - - -

News:
- Press Releases
- Blog

Resources:
- Wiki
- Sources
- Downloads
- Governance
- Security Information

Connect:
- Mailing Lists
- Search Mailing Lists
- IRC
- Twitter
- LinkedIn

Miscellaneous:
- Contact us
- Legal and Privacy
- Trademark and Logos
- Merchandise
- Jobs in the Community

+ + + + + + + + + + + + + +

News:
+Press Releases
+Blog

Resources:
+Wiki
+Sources
+Downloads
+Governance
+Security Information

Connect:
+Mailing Lists
+Search Mailing Lists
+IRC
+Twitter
+LinkedIn

Miscellaneous:
+Contact us
+Legal and Privacy
+Trademark and Logos
+Merchandise
+Jobs in the Community

- - - - - + + + +

- Copyright - - - Citrix Systems, Inc. All rights reserved. -
+ Copyright + + +Citrix Systems, Inc. All rights reserved. +

- - +

- - - - + + + +

	- Xen.org's servers are hosted with RackSpace, monitoring our - servers 24x7x365 and backed by RackSpace's Fanatical Support®. -
	+ Xen.org's servers are hosted with RackSpace, monitoring our +servers 24x7x365 and backed by RackSpace's Fanatical Support®. +

- -