OPEN DATA CENTER ALLIANCE SM USAGE MODEL: PROVIDER ASSURANCE REV. 3.0

OPEN DATA CENTER ALLIANCE SM USAGE MODEL: PROVIDER ASSURANCE REV. 3.0 Version Date Editor Description of Change 3.0 27 Aug 2014 Security WG Secure Software Development Lifecycle added Contributors Albert Caballero Trapezoid Christophe Gévaudan UBS Tino Hirschmann T-Systems, Deutsche Telekom Group Stephen Huang Bingosoft Ian Lamont BMW Matt Lowth National Australia Bank Manjunath Mahabhaleshwar Intel IT Robert Rounsavall Trapezoid Avi Shvartz Bank Leumi Jose Souza UBS

OPEN DATA CENTER ALLIANCE SM : Page 2 of 16 CONTENTS Contributors... 1 Executive Summary... 4 Purpose... 5 Taxonomy... 6 Usage Model Diagram... 6 Usage Model Details... 6 Usage Model Scenarios... 7 Usage Requirements: Security... 8 Proposal for Initial Security Requirements... 8 Detailed Security Requirements for Assurance Levels... 11 Vulnerability Management... 11 Network and Firewall Isolation... 11 Identity Management... 11 Security Incident and Event Monitoring (SIEM)... 12 Secure Software Development Life Cycle (SSDLC)... 12 Provider Risk Assessment and Management... 12 Encryption Key Management... 13 PaaS and SaaS Source Code Analysis... 13 Data Retention and Deletion... 13 IT Security Policy... 14 RFP Requirements... 15 Summary of Industry Actions Required... 16

OPEN DATA CENTER ALLIANCE SM : Page 3 of 16 Legal Notice This Open Data Center Alliance SM Usage Model: Provider Assurance 3.0 document is proprietary to the Open Data Center Alliance (the Alliance ) and/or its successors and assigns. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Alliance Participants are only granted the right to review, and make reference to or cite this document. Any such references or citations to this document must give the Alliance full attribution and must acknowledge the Alliance s copyright in this document. The proper copyright notice is as follows: Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way without the prior express written permission of the Alliance. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Alliance Participants is subject to the Alliance s bylaws and its other policies and procedures. NOTICE TO USERS GENERALLY: Users of this document should not reference any initial or recommended methodology, metric, requirements, criteria, or other content that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. The contents of this document are intended for informational purposes only. Any proposals, recommendations or other content contained in this document, including, without limitation, the scope or content of any methodology, metric, requirements, or other criteria disclosed in this document (collectively, Criteria ), does not constitute an endorsement or recommendation by Alliance of such Criteria and does not mean that the Alliance will in the future develop any certification or compliance or testing programs to verify any future implementation or compliance with any of the Criteria. LEGAL DISCLAIMER: THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN AS IS BASIS. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ALLIANCE (ALONG WITH THE CONTRIBUTORS TO THIS DOCUMENT) HEREBY DISCLAIM ALL REPRESENTATIONS, WARRANTIES AND/OR COVENANTS, EITHER EXPRESS OR IMPLIED, STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, VALIDITY, AND/OR NONINFRINGEMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND THE ALLIANCE MAKES NO REPRESENTATIONS, WARRANTIES AND/OR COVENANTS AS TO THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF, OR RELIANCE ON, ANY INFORMATION SET FORTH IN THIS DOCUMENT, OR AS TO THE ACCURACY OR RELIABILITY OF SUCH INFORMATION. EXCEPT AS OTHERWISE EXPRESSLY SET FORTH HEREIN, NOTHING CONTAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY KIND OF LICENSE IN THE DOCUMENT, OR ANY OF ITS CONTENTS, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY INTELLECTUAL PROPERTY OWNED OR CONTROLLED BY THE ALLIANCE, INCLUDING, WITHOUT LIMITATION, ANY TRADEMARKS OF THE ALLIANCE. TRADEMARKS: OPEN CENTER DATA ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo are trade names, trademarks, and/or service marks (collectively Marks ) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document does not grant any user of this document any rights to use any of the ODCA s Marks. All other service marks, trademarks and trade names reference herein are those of their respective owners.

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 4 of 16 OPEN DATA CENTER ALLIANCE SM USAGE MODEL: PROVIDER ASSURANCE REV. 3.0 Executive Summary In many organizations today, there is a significant push towards introducing cloud computing into the enterprise. The hope is that the cloud s multi-tenant, shared infrastructure will enable greater computing efficiency and flexibility. At the same time, organizations require that compute platforms are secure and comply with all relevant rules, regulations and laws. These requirements must be met whether using a dedicated service available via a private cloud or a service shared with other subscribers via a public cloud. There s no margin for error or security breaches. According to a research study conducted by the Ponemon Institute and Symantec, the average organizational cost of a data breach in 2010 increased to $7.2 million, and the cost of lost business was about $4.5 million. 1 It is the high cost of breaches and unclear and inadequate security assurances offered as part of cloud services that create a barrier to the wider adoption of cloud computing and create resistance within organizations to public cloud services. The Open Data Center Alliance SM (ODCA SM ) recognizes that security is the biggest challenge organizations face as they plan for migration to cloud services. This Usage Model provides standard definitions of security for cloud services, details mechanisms for service providers to demonstrate compliance, and seeks to give organizations the ability to validate adherence to security standards within cloud services. This document serves a variety of audiences. Business decision makers looking for specific solutions, and enterprise IT groups involved in planning, operations, and procurement will find this document useful. Solution providers and technology vendors will benefit from its content to better understand customer needs and tailor service and product offerings. Standards organizations will find the information helpful in defining standards that are open and relevant to end users. 1 See The Cost of Data Breach Study, March 2012 at: www.ponemon.org/local/upload/file/2011_us_codb_final_5.pdf

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 5 of 16 Purpose This Usage Model seeks to define requirements for standardized definitions of security levels within the cloud. Used with the companion ODCA Usage Model on Security Monitoring, 2 it seeks to assist cloud subscribers to: Help a cloud provider to meet certain standards and common levels of security Compare security levels between different providers of cloud services and between internally and externally hosted clouds Help organizations that subscribe to cloud services to make more informed choices on the levels of security they may want to adopt, based on the confidentiality, integrity and availability requirements of their hosted solutions The intent for this Usage Model is to define the security requirements for cloud computing and implement a framework to assure against them. To do this, the Usage Model seeks to define minimum levels for cloud security within tiers. These tiers will provide offerings with increasing levels of security to help meet the requirements of organizations that subscribe to cloud services. These levels are: Assurance Level Description Represents the lower-end corporate security requirement and may equate to a higher level for a small to medium business customer Represents a standard level of corporate security likely to be evident in many enterprises Represents an improved level of security that would normally be associated with the processing of sensitive corporate data. Represents the highest level of contemplated corporate requirements Example Development environment Test environment; out-ofthe-box production environment Finance sector production environment Special purpose, high-end security requirement The above table represents the security perspective of the levels,,, and. For a general overview, reference should be made to the Standard Units of Measure 2 document on the ODCA website. The use of these assurance standards (i.e., delivering accredited,,, or services), will assist the cloud provider to be able to show demonstrable evidence of its security posture. This will then help the provider to issue templated responses to answer potential customer security concerns. This also will help to foster a level of trust with the customer through the continued accreditation to these standards. It is anticipated that the provider of cloud services may be able to self-certify to the levels; however, it will be required to undertake third-party certification to assure to the higher levels. The base-level requirements defined in the Provider Assurance Model aim to give the provider of cloud services the ability to differentiate their services by offering more than the standard, while giving customers confidence that systems are securely maintained. It is also envisioned that while a provider of cloud services may be certified to levels of security, that provider may also choose to offer lower levels (such as or ) by providing solutions that meet the security requirements for those levels. The individual requirements listed below are intended to be independent of the technology used by the cloud provider. For example, firewall isolation of a subscriber s system may be achieved by virtual firewalls when using software-defined networks. In a 2012 opinion on Cloud Computing, the European Union 3 defined a series of parameters which should be addressed in order to mitigate the risk associated with moving personal data to the cloud. The stated parameters were Availability, Integrity, Confidentiality, Transparency, Isolation (purpose limitation), Intervenability, Portability, and Accountability. Through these, the European Union seeks to provide guidance on how to secure cloud environments in order to comply with European law. This document is intended to provide guidance which supports the compliance with this and similar requirements. 2 www.opendatacenteralliance.org/library 3 01037/12/EN: WP 196: Opinion 05/2012 on Cloud Computing: (http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2012/wp196_en.pdf)

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 6 of 16 Taxonomy Actor Cloud Subscriber Cloud Provider Description A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. An organization providing network services and charging cloud subscribers. A (public) cloud provider provides services over the Internet. Cloud Compliance Agency An accredited entity that is responsible for ensuring the compliance to cloud security standards. A cloud compliance agency may also be a third party trusted by the cloud subscriber. They could then determine and monitor the security state of the cloud provider and respond to the cloud subscriber when requested. Cloud Standards Body An entity responsible for setting and maintaining the cloud security standards as defined in this Usage Model. Usage Model Diagram Usage Model Details Managing risks in interacting with cloud providers requires a process to provide an appropriate assurance level. While a cloud provider may support many levels of assurance, it is the cloud subscriber s responsibility to evaluate its risk appetite and determine the appropriate level of security required. This evaluation may be done by the cloud subscriber when choosing a particular cloud provider or when selecting a security assurance level. This may also be done as part of the negotiation between the cloud subscriber and cloud provider. Some examples of security concerns, which may be addressed by progressing to a higher level of security assurance, are shown below: Level at Which Risks Should Be Diminished Deployment Considerations Loss of Governance Lock In (No Standardized Data) Isolation Failure Compliance Risks

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 7 of 16 Level at Which Risks Should Be Diminished Deployment Considerations Management Interface Compromise Data Protection Insecure or Incomplete Data Deletion Malicious Insider Intercepting Data in Transit Distributed Denial of Service Loss of Encryption Keys Network Breaks Usage Model Scenarios Goals: To provide standardized definitions of security for cloud-based services in the areas of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) so that cloud subscribers can better compare and understand different cloud offerings. This will, in turn, help to increase the efficiencies of managing multiple cloud providers. To give cloud providers the ability to demonstrate compliance to an agreed standard through certification processes maintained by a cloud compliance agency. To give cloud subscribers the ability to validate adherence to cloud security standards either by direct assessment or third-party accreditation. Assumptions: Cloud providers must follow compliance reporting standards as detailed in Open Data Center Alliance Usage: Cloud Security Monitoring. 4 Success Scenario 1 (full): The cloud standards body defines standards and a number of cloud providers gain certification through cloud compliance agencies. Cloud providers advertise services that demonstrate compliance to standards and consistently meet the standards. Failure Condition 1: The cloud provider advertises a higher level of security than actually exists and claims certification when none exists. This leads to the situation where the cloud subscriber purchases services that do not exist and creates significantly greater risk for the cloud subscriber. The cloud provider achieves certification, but then does not maintain the required processes. This means that the cloud subscriber faces varying levels of risk dependent on the level of deviation from the standards. Success Scenario 2 (partial): The cloud standards body ratifies a number of standards, but no certification processes are established. The cloud provider accepts responsibility to operate to the standards and regularly achieve the required levels. 4 www.opendatacenteralliance.org/library

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 8 of 16 Failure Condition 2: The cloud provider advertises a higher level of security than actually exists and claims to adhere to the standards without achieving them. This leads to a situation where the cloud subscriber purchases services that do not meet the required security level, resulting in significantly greater risk for the cloud subscriber. The cloud provider achieves the required standard when the contract is initiated, but then does not maintain the required processes. This means that the cloud subscriber faces varying levels of risk dependent on the level of deviation from the standards. Failure Handling: For all failure scenarios, the monitoring prescribed by the Security Monitoring Usage Model 5 would identify deviations from the standard, thereby allowing the cloud subscriber to take necessary actions to reduce risk. Usage Requirements: Security The information below is designed to inform cloud providers of the requirements sought by members of the Open Data Center Alliance when procuring cloud services. It is expected that cloud providers will be able to demonstrate compliance to the various levels to provide transparency of the security of the cloud services offered. Proposal for Initial Security Requirements Note: This is not yet an exhaustive list, and it is envisioned that the list will be expanded as the Usage Model matures. Further details to a number of sections are provided below the summary table. Level at Which Each Capability is Offered Relevant Service Security Requirement IaaS PaaS SaaS 1 Antivirus and malware protection (with definition updates within 24 hours) 2 Vulnerability management process exists and is fully tested to ensure no impact to target or application (further details below) 3 Network and firewall isolation of cloud subscriber s systems with management as described below 4 Physical access control into cloud data center 5 Secure protocols used for remote administration (e.g. SSH, RDP, Cloud Management etc.) 6 All default passwords and guest access removed 7 Mandatory use of non-disclosure agreements (NDAs) for cloud provider staff 8 Mandatory use of Information Technology Infrastructure Library (ITIL) processes for change, incident, and configuration management 9 Identity management for subscriber s assets as described below 10 Data retention and deletion managed as described below 5 www.opendatacenteralliance.org/library

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 9 of 16 Level at Which Each Capability is Offered Relevant Service Security Requirement IaaS PaaS SaaS 11 Security incident and event monitoring as described below 12 Network intrusion prevention; updates applied within 48 hours 13 Event logging for all administration-level events (requires controlled access to logs) 14 Four-eye principle for key administrator changes 15 Cloud provider has an implemented and tested technical continuity plan Recovery time and recovery point objective provided to subscriber at commencement of contract 16 Fully documented and controlled provider platform (details include network, systems, management, etc.) 17 Systems must be developed using a Secure Software Development Life Cycle (as defined below) 18 Cloud provider performs regular risk assessments (e.g., penetration testing) and remediates issues as defined below 19 Option for subscriber to perform penetration testing on hosted systems and applications 20 Physical segmentation of hardware (server, storage, network, etc.) to ensure isolation from all other systems 21 Encrypted communication between cloud provider and cloud subscriber 22 Multi-factor authentication 23 Ability for cloud subscriber to define geographic limits for hosting 24 No default administrative access for cloud subscriber systems and applications. Access solely through a controlled mechanism with agreement of the subscriber 25 Strong encryption mandatory for all data in-flight and at rest 26 Logical separation of workloads 27 Provider staff management procedures (leaving, background check, etc.) 28 Continuous training in the areas of IT security and data privacy for cloud provider staff as well as regulatory requirements. 29 Safe Harbor or equivalent (when EU data is processed) 30 IT Security Policy covering all provider staff is in place (see below) 31 SaaS/PaaS source code analysis (see below) 32 Wireless security at provider sites (WPA, WEP, etc.)

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 10 of 16 Level at Which Each Capability is Offered Relevant Service Security Requirement IaaS PaaS SaaS 33 Device authentication (with certificate) to provider WLAN 34 Mobile device data wipe 35 Provider processes (e.g., VM migration) should be certified to ISO27000/27001 or equivalent 36 Encryption key management as detailed below 37 Cloud provider has full configuration management to enable location of all physical and software assets 38 Cloud provider can locate, in real time, all physical assets, all software assets, and subscriber s data 39 Full and guaranteed disposal of all of the subscriber s data/information from system/application that are no longer used 40 Full and verifiable deletion of subscriber s data 41 Denial of Service (DoS) protection capability available to protect the cloud subscriber s service 42 Subscriber related application event logging is provided. The event logging should enable the subscriber to comply to audit requirements. 43 Mechanisms to protect data (such as anonymization and tokenization) from threats such as misuse or leakage

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 11 of 16 Detailed Security Requirements for Assurance Levels Vulnerability Management A vulnerability management process that ensures installation of system and software patches within the targets is identified below. The test process must ensure proper function of the patch and compatibility to the actual target systems with no negative impact on resource utilization (i.e., memory and CPU consumption). Vulnerabilities with a basic Common Vulnerability Scoring System (CVSS) score of greater than 9 (or those rated as High by Microsoft or other vendors) must be patched within 96 hours; all others within 1 month. Vulnerabilities with a basic CVSS score of greater than 5 (or those rated as Medium or High by Microsoft or other vendors) must be patched within 96 hours; all others within 1 month. Vulnerabilities with a basic CVSS score of greater than 2 (or those rated as Low, Medium, or High by Microsoft or other vendors) must be patched within 96 hours; all others within 1 month. All vulnerabilities must be patched within 24 hours of their release by the vendor. Network and Firewall Isolation Network segregation and firewalls are required to protect all assets managed in the cloud. The level of involvement of the cloud provider in the management of firewall rule sets will vary depending on the level of service offered. The firewall rule sets are managed by the cloud provider with no direct involvement of the cloud subscriber. The firewall rule sets are managed by the cloud provider with changes advised to the cloud subscriber before implementation. The cloud provider should offer network segmentation between logical tiers. The firewall rule sets are managed by the cloud subscriber. The cloud provider retains access to the firewall at the administrator level in order to provide system maintenance. The cloud provider must offer network segmentation between logical tiers and should offer Layer-7 protection to prevent application-level attacks. The cloud provider has no access to firewalls. All admin tasks including rule updates are managed by the cloud subscriber. The cloud provider must offer network segregation between logical tiers and Layer-7 protection to prevent application-level attacks. Identity Management All services in the cloud must be secured by authentication management systems. Basic username and password systems will exist. Passwords may be basic (but must exist) and no requirement for password aging or reuse exists. Basic username and password systems will exist. Strong passwords must be used (e.g., minimum character length of 8 characters, multiple types of characters) and an agreed password aging and reuse policy exists. Service access should support Single Sign-On (SSO) integration using standards-based assertions. System and privileged access must be secured using identity federation or strong authentication (i.e., two-factor authentication). In addition to normal passwords, a second secret must be used: a one-time password or a physical token. Service access must support SSO integration using standards-based assertions. System and privileged access must be secured using identity federation or strong authentication (i.e., two-factor authentication). In addition to normal passwords, a unique biometric password system must be used. Service access must support SSO integration using standards-based assertions.

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 12 of 16 Security Incident and Event Monitoring (SIEM) The cloud provider must ensure that any security-related events are advised to the cloud subscriber. The minimum requirements for each level are listed below. A SIEM process exists and is operated during normal working hours. Responsibility is assigned within the cloud provider s organization. Notification of security-related events is forwarded to the cloud provider within 48 hours of the event. A SIEM process exists and is operated 24x7x365. Responsibility is assigned within the cloud provider s organization. Notification of security-related events is forwarded to the cloud provider within 24 hours of the event. Security event forwarding to cloud subscriber s system is possible. A SIEM process exists and is operated 24x7x365. A dedicated team exists and is known to the cloud subscriber. Notification of security-related events is forwarded to the cloud provider within 2 hours of the event. Security event forwarding to cloud subscriber s system is mandatory (where such a system exists). SIEM is managed by the cloud subscriber. Security events from the cloud provider s environment must also be forwarded. Secure Software Development Life Cycle (SSDLC) The cloud provider must ensure that security is integrated into the software development process. The minimum requirements for each level are listed below. A managed SSDLC process is operated. It includes basic requirements such as versioning, secure coding guidelines and documentation. A managed SSDLC process is operated. Additionally to the requirements, it is ensured that development, QA and production environment are strictly separated. Code is regularly checked via automated tools during the development process as well as manual by internal parties before go live. Checksums are provided for productive code and the process usage is regularly monitored. A quantitatively managed SSDLC process is operated. In addition to the requirements, external code (e.g. 3 rd party libraries and APIs) is treated like internal code and is also subject to regular automated testing. Product security is regularly tested by external parties. An optimized SSDLC process is operated. In addition to the requirements, source code and products are tested and verified by multiple internal and external parties. Products are certified against well known security standard, such as Common Criteria. Provider Risk Assessment and Management Cloud providers are required to understand the IT security risks associated with all aspects of the services that they offer. This requires regular testing and reporting in line with the details below. At level and above the specific results from tests and the actions taken to remediate any identified risks should be made available. All reports should be kept for a minimum of 5 years or longer if required to for legal reasons. Cloud provider to perform annual risk assessments. Risks are to be internally evaluated, risk management plans should be in place, and significant risks remediated within 90 days. No reporting to subscriber is required. Cloud provider to perform annual risk assessments. Risk assessments are to be carried out by a third party to the operation of the service. Risks are to be internally evaluated, risk management plans should be in place, and significant risks remediated within 90 days. Generalized reporting covering aspects such as the number of risks identified during the test and the general nature of these risks should be made available to cloud subscribers on request. Cloud provider to perform bi-annual risk assessments. Risk assessments are to be carried out by a third party to the group operating the service. Risks are to be internally evaluated, risk management plans should be in place, and significant risks

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 13 of 16 remediated within 30 days. Specific reports specifying all identified risks and specific management plans should be made available to cloud subscribers. Cloud provider to perform bi-annual risk assessments. Risk assessments are to be carried out by a third party to the cloud provider. Risks are to be externally rated, risk management plans should be in place, and significant risks remediated within 30 days. Specific reports specifying all identified risks and specific management plans should be sent to cloud subscribers. Encryption Key Management Encryption key management will, as required below, be provided by the cloud provider in line with industry best practices. Cloud provider will provide key management capability through systems shared by multiple subscribers. Cloud provider will provide key management capability through systems shared by multiple subscribers and will provide support for subscriber key management systems as required. Cloud provider will provide key management capability through systems unique to a single subscriber and will provide support for subscriber key management systems as required. Management provided by the cloud subscriber s systems (unless otherwise agreed between cloud subscriber and provider). PaaS and SaaS Source Code Analysis All software products developed by the cloud provider are required to be evaluated for security issues using the four eyes principle. Internal source code reviews should be carried out by qualified staff who are independent from the development teams. Reviews are to be carried out based on the items in the following list. Internal review of code for new releases only. Internal review of code for new releases and version updates. Review performed by external third party for new releases and version updates. All operational software components to be reviewed once every 2 years Review performed by external third party for new releases and version updates. All operational software components to be reviewed annually. Data Retention and Deletion The cloud provider must ensure that there are adequate controls to support the cloud subscriber s requirements for Information Handling and Data Retention/Deletion. In particular, all data whether transient or fixed remains the property of the cloud subscriber at all times. The minimum requirements for each level are listed below. Data stored on the cloud provider s systems must be deleted when instructed by the cloud subscriber (whether through software or any other means). Data stored on the cloud provider s systems must be deleted when instructed by the cloud subscriber (whether through software or any other means) and all transient cloud subscriber data tied to a particular user session should be deleted at termination of that session. The cloud subscriber can define retention policies that can be honored by the cloud provider s process and automation; full and guaranteed disposal of all data/information from systems that are no longer used by cloud subscriber (session-based for dynamically allocated resources and at end of contract for dedicated systems). The cloud subscriber can manage retention policies directly as per their processes (highly automated environment with self-

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 14 of 16 help capabilities provided by the cloud provider). IT Security Policy The cloud provider must ensure that there are adequate policies in place to ensure that staff employed by the provider understand their responsibilities to the customer. The policy will prevent improper processing, disclosure, alteration, or destruction of subscriber s data.

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 15 of 16 RFP Requirements Following are requirements that the Alliance suggests should be included in requests for proposal (RFP) to cloud providers to ensure that security requirements are met according to four support levels (,,, and ). ODCA Principle Requirement Solution is open, works on multiple virtual and non-virtual infrastructure platforms, and is standards-based. Describe how the solution meets this principle and any limitations it has in meeting these goals. ODCA Provider Assurance Usage Model Rev 2.0 Solution must allow assurance levels to be represented and tracked in the SIEM and compliance monitoring tools. ODCA Provider Assurance Usage Model Rev 2.0 Solution must be able to support the following security requirements by support level 6 : level must be able to provide all of the following: Antivirus and malware protection (with definition updates within 24 hours) Vulnerability management process exists and is fully tested to ensure no impact to target or application Network and firewall isolation of cloud subscriber s systems with management Physical access control into cloud data center Secure protocols used for remote administration (e.g., SSL, SSH, RDP, etc.) All default passwords and guest access removed Mandatory use of non-disclosure agreements (NDAs) for cloud provider staff Mandatory use of Information Technology Infrastructure Library (ITIL) processes for change, incident, and configuration management Identity management for subscriber s assets Data retention and deletion management Security incident and event monitoring level must be able to provide all of the security requirements for level, plus the following: Network intrusion prevention; updates applied within 48 hours Event logging for all administration-level events (requires controlled access to logs) Four-eye principle for key administrator changes Cloud provider has an implemented and tested technical continuity plan Fully documented and controlled network Systems must be developed using Secure Software Development Life Cycle Coding Standards level must be able to provide all of the security requirements for level, plus the following: Option to perform penetration testing on hosted systems and applications Physical segmentation of hardware (server, storage, network, etc.) to ensure isolation from all other systems Encrypted communication between cloud provider and cloud subscriber Multi-factor authentication Ability for cloud subscriber to define geographic limits for hosting level must be able to provide all of the security requirements for level, plus the following: No default administrative access for cloud provider staff Strong encryption mandatory for all data in-flight and at rest ODCA Provider Assurance Usage Model Rev 2.0 Solution must be able to provide clear guidance to allow a cloud subscriber to make an informed choice on the security level they require for their solution. 6 Note: These security requirements are current as of June 10th, 2013. Please refer to the ODCA Security Monitoring Usage Model for updates before making any changes to RFP requirements.

OPEN DATA CENTER ALLIANCE SM : Provider Assurance Rev. 3.0 Page 16 of 16 ODCA Provider Assurance Usage Model Rev 2.0 Solution must be able to protect the cloud subscribers information both in-flight and at rest. For further assistance in developing an RFP, please use this online engine: www.opendatacenteralliance.org/ourwork/proposalengineassistant Summary of Industry Actions Required In the interest of giving guidance on how to create and deploy solutions that are open, multi-vendor and interoperable, we have identified specific areas where the ODCA suggests there should open specifications, formal or defacto standards or common intellectual property-free (IP-free) implementations. Where the ODCA has a specific recommendation on the specification, standard or open implementation, it is called out in this Usage Model. In other cases, we plan to work with the industry to evaluate and recommend specifications in future releases of this document. The following are industry actions required to refine this Usage Model: 1. Cloud providers and other interested parties are requested to review their cloud offerings against each of the required security levels (,,, ). 2. Cloud providers are requested to submit compliance declarations (in other words, does the cloud provider currently offer security to any of the defined levels) and any non-conformances to the Open Data Center Alliance SM Security Working Group for discussion.