Dear Community Members, before Christmas, the Xen Project ran a community consultation to refine its Security Problem Response Process. We recently approved changes that, in essence, are tweaks to our existing process, which is based on the Responsible Disclosure philosophy. Responsible Disclosure and our Security Problem Response Process are important components of keeping users of Xen Project based products and services safe from security exploits. Both ensure that products and services can be patched by members of the pre-disclosure list before details of a vulnerability are published andbefore said vulnerabilities can be exploited by black hats. The changes to our response process fall into a number of categories: - Clarify whether security updates can be deployed on publicly hosted systems (e.g. cloud or hosting providers) during embargo
- Sharing of information among pre-disclosure list members
- Applications procedure for pre-disclosure list membership
The complete discussion leading to the changes, the concrete changes to the process, and the voting records supporting the changes are tracked in Bug #44 -Security policy ambiguities. On February 11, 2015, the proposed changes were approved in accordance with Xen Project governance. Note that some process changes are already implemented, whereas others are waiting for new tooling before they can fully be put in place. We have however updated our Security Problem Response Process as most tooling is present today. Process Changes Already in OperationThe updated policy makes explicit whether or not patches related to a Xen Security Issue can be deployed by pre-disclosure list members. The concrete policy changes can be found here and here. In practice, every Xen Security Advisory will contain a section such as: DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team. This section will clarify whether deploying fixed versions of Xen during the embargo is allowed. Any restrictions will also be stated in the embargoed advisory. The Security Team will impose deployment restrictions only to prevent the exposure of security vulnerability technicalities, which present a significant risk of vulnerability rediscovery (for example, by visible differences in behaviour). Such situations have been, and are expected, to be rare. Changes to Application Procedure for Pre-disclosure List MembershipWe also made additional changes related to streamlining and simplifying the process of applying for pre-disclosure list membership. Detailed policy changes can be found here and here. Moving forward, future applications to become members of the Xen Project pre-disclosure list have to be made publicly on the predisclosure-applications mailing list. This enables Xen Project community members to provide additional information and also is in line with one of our communityâs core principles: transparency. In addition, weâve clarified our eligibility criteria to make it easier for the Xen Project Security Team, as well as observers of the mailing list, to verify whether applicants are eligible to become members of the list. Process Changes That Require Some ToolingSharing of Information Among Pre-disclosure List MembersFinally, members of the pre-disclosure list will be explicitly allowed to share fixes to embargoed issues, analysis, and other relevant information with the security teams of other pre-disclosure members. Information sharing will happen on a private and secure mailing list hosted by the Xen Project. More details here. Best Regards Lars
| 
