...

If you believe you have discovered a potential security issue with CloudStack, please follow the procedure on the CloudStack Security Page (need to link this somewhere).

Procedure for responding to potential security issues:

During the investigation and mitigation of a security issue, the CloudStack PPMC may involve other members of the community as necessary to verify a vulnerability or work on its mitigation.

This document describes the procedures that will be used to respond to a reported vulnerability.

Security Team

The PPMC has decided to create a "Security Team" for CloudStack.  The Security Team's charter is to manage the response to vulnerabilities reported with Apache CloudStack.  This includes communication with the report, issue verification, issue correction, public communication creation, and vendor coordination.  The Security Team may ask assistance from other community members to help verify or correct a reported issue.

Initially, the Security Team consists of the members of the PPMC.

Community members engaged by the Security Team are expected to hold the issue in confidence until public announcement of the vulnerability.  This protects the users of the software and gives reasonable time for the response process to be implemented.  Further information can be found on the ASF's How it Works page.

Scope

The scope of these procedures applies to vulnerabilities found in CloudStack releases 4.0.0-incubating and later. 

CloudStack has an history that pre-dates the Apache Software Foundation.  This includes the 2.0.x, 2.1.x, 2.2.x, and 3.0.x series of CloudStack releases. Vulnerabilities that are present in only these releases will be addressed by Citrix.

Some vulnerabilities may exist in ASF code releases as well as derivative works or binary distributions.  This is discussed in the Distributors section below.

Procedure for responding to potential security issues

• Upon receiving notice of a potential security issue, a security team member will create a bug to track the investigation, this bug must be flagged as a security issue. Security flag should mean contents of ticket are not visible to non-security team members
• Security team investigates the issue to confirm/deny the presence of a vulnerability within CloudStack
• If the issue is determined not to be a vulnerability the reporter will be notified and the issue will be closed as invalid.
• If issue is confirmed as a CloudStack vulnerability:
  • Security team notifies the Apache Security team
  • Security team assigns a risk rating to the vulnerability using the Common Vulnerability Scoring System
  • Security team works with reporter to get a chance to investigate and mitigate the issue in a timely manner before public announcement. This should be between 15-30 days, depending on the severity and complexity of the issue
  • Security team works with Apache Security Team to reserve a CVE Identifier for future public release
  • Security team works with appropriate code maintainer(s) to create patch to mitigate the issue
  • Testing is conducted to verify patch mitigates issue and does not cause regression errors
  • Security team creates a vulnerability announcement
  • Patch is committed to trunk and other supported branches that are affected.  The commit should not refer to a particular vulnerability.
  • A new CloudStack release or hotfix is prepared and tested, containing the new security patch.
  • Distributor coordination is implemented to enable a coordinated announcement.
  • Security team posts vulnerability announcement to...
    • CloudStack dev list
    • CloudStack users list
    • CloudStack Security alerts web page
    • The Bugtraq mailing list
  • After announcement, CHANGES and NEWS files need to be updated to reflect the vulnerability and fix. This must happen AFTER the announcement.
  • Also after announcement, modify the Jira ticket so that the issue is now publicly viewable.
• After the vulnerability is addressed, the CloudStack community should review development processes to see how the community can minimize the chance of similar vulnerabilities being introduced in the future.

Vendor Coordination

Potential security issues must be treated in a sensitive manner by all parties involved. Early release of vulnerability details can place large numbers of CloudStack installations at risk for compromise. The CloudStack community realizes that committers may be employed by companies who provide their customers with CloudStack products. It is understandable that these companies may be very interested to get advanced notification of security issues, but any breeches of sensitive information prior to an official announcement of the vulnerability and mitigation will not be tolerated. CloudStack committers participate as individuals, and when interacting with the project they must act in the best interests of the Apache Software Foundation. Further information can be found on the ASF's How it Works page.

The CloudStack PPMC is happy to work with vendors during the process of responding to a security response in the following manner:

• Initial security information is only shared on a need-to-know basis outside the PPMC to verify the issue and work on mitigation.
• It is expected that for committers who are employed by companies using CloudStack, it is likely the companies will learn about the vulnerability before the general public. What must be stressed is the company must ensure the confidentiality of the issue before general release.
• As an issue is verified and mitigation is developed and tested, the security team will communicate the latest information to all involved. For companies who have employees on the security team, this can allow them to prepare (not publish) announcements and patches to provide to their customers.
• During the response procedure, the security team will communicate their timeline. This is done to allow both security team members and their employers to prepare their own announcements and patches for their customers.
• The target result is an orchestrated, simultaneous announcement across CloudStack and vendors. It is expected that the CloudStack security team may announce shortly before vendors - we are ultimately responsible for CloudStack and to our community. The reverse, where vendors announce before CloudStack, is not acceptable.

...

Distributor coordination

CloudStack operates a pre-disclosure list. This list contains the email addresses of the security response teams for significant CloudStack distributors.  This includes both corporations and community institutions.  The purpose of the pre-disclosure list is to enable the CloudStack project and distributors to participate in a bi-directional information sharing agreement for vulnerabilities.  By joining the pre-disclosure list the organization and ASF mutually agree to jointly share vulnerability information that is originally reported to them, jointly verify and fix issues, and jointly (simultaneously) make vulnerability announcements and hotfix releases (if warranted) to the public.  The ASF and organizations on the pre-disclosure list are also expected to be reasonably responsive, with a guided expectation of 2-4 weeks to verify issues and release fixes (if warranted).  Response times should be discussed and agreed upon depending on the issue severity.

Pre-disclosure list members are expected to maintain the confidentiality of the vulnerability up to the embargo date that has been agreed to with the discoverer. Prior to the embargo date, pre-disclosure list members should not make available, even to their own customers and partners:

• the ASF 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 the Security Team

List members are allowed to make available to their users only the following:

• The existence of an issue
• The assigned CVE numbers
• The planned disclosure date

Organizations on the pre-disclosure list

The Security Team defines which organizations are admitted to the pre-disclosure list.  Generally, well-established organizations with a mature security response process will be considered on a case-by-case basis.  Organizations that meet the criteria should contact XXX (we need a cloudstack-security mailing list) if they wish to participate in the pre-disclosure activities.  The list of entities on the pre-disclosure list is public. No organization may privately receive pre-disclosure information.

This is a list of organizations on the pre-disclosure list

• Citrix