Chapter 6
Certification for Cloud Service Providers
Abstract
While the previous chapter presents the security controls to mitigate the threat, the reality is that for many end customers their ability to influence the security measures will be limited. Indeed, even the level of transparency into the controls deployed will be limited. This is why cloud certifications will be so important; they are used more and more as the vehicle to provide assurance regarding the security deployed by providers to potential customers.
Keywords
CAIQ; Certification; FedRAMP; StarFor end customers of cloud computing, the chapter that discussed the security for cloud providers would have made interesting reading but the reality is that this level of visibility is rarely available. In the majority of cases, the use of certifications is the primary vehicle for providing assurance to customers, both current and potential. The role of certifications can therefore be used to provide a degree of trust into the security deployed by the provider, but may also be a mandatory requirement for customers within specific geographies or industry verticals.
The purpose of this chapter is to review the various cloud security certifications available. As expected, a multitude of standards each with their varying strengths is available. Also detailed within this chapter are Cloud Security Alliance (CSA) certifications that were briefly referenced in Chapter 2, which includes the Cloud Controls Matrix (CCM) as well as the Consensus Assessments Initiative Questionnaire (CAIQ).
Certification for Cloud Service Providers
The title for this particular section is a little misleading; this is because although a number of information security-related certifications exist specifically for cloud computing, there exist considerably more that are used for traditional IT environments, and that have been adopted by Cloud Service Providers (CSP). There have also been many books dedicated to these individual standards (for example, the excellent book by co-author Brian Honan entitled “ISO 27001 in a Windows environment”1). Subsequently, the intention is not to detail how to apply the various standards, but rather provide the reader with an understanding of what is available, and the relative merits of each standard. In particular where and why a standard would be used as opposed to another? For a broader assessment of the various certification schemes (beyond security), please refer to the November 2013 publication by ETSI entitled “Cloud standards coordination.”2 The following are some of the common security frameworks used by CSP; this list is certainly not exhaustive and therefore the reader is encouraged to review the ETSI document as well as guidance developed by ENISA.3
CSA Open Certification Framework
Introduced in Chapter 2, the open certification framework (OCF) “is an industry initiative to allow global, accredited, trusted certification of cloud providers.”4 Based on the research conducted by the CSA Governance Risk and Compliance (GRC) stack, the OCF supports a number of assurance tiers ranging from self-certification to continuous monitoring as defined within Chapter 2 (under STAR). The structure of OCF is graphically illustrated in Figure 6.1.
Detailed in Chapter 2, this open framework is particularly helpful to potential customers in achieving transparency into the security controls deployed by service providers. The foundation for the framework is based upon the outputs from the GRC stack and in particular the CCM and CAIQ.
CSA GRC Stack – CCM
The CCM provides the core security principles for CSP which can be used to articulate their security maturity to potential end customers. Originally released as version 1.0 in April 2010, the latest revision is currency at v.3.0 that was released in March 2013. Version 3 of the matrix itself is comprised of a total of 16 domains each containing a varying number of controls that are organized into subdomains. These domains are as follows:
▪ Domain 1: Application and interface security
▪ Domain 3: Business continuity management and operational resilience
▪ Domain 4: Change control and configuration management
▪ Domain 5: Data security and information lifecycle management
▪ Domain 6: Datacenter security
▪ Domain 7: Encryption and key management
▪ Domain 8: Governance and risk management
▪ Domain 9: Human resources
▪ Domain 10: Identity and access management
▪ Domain 11: Infrastructure and virtualization security
▪ Domain 12: Interoperability and portability
▪ Domain 13: Mobile security
▪ Domain 14: Security incident management, E-discovery, and cloud forensics
▪ Domain 15: Supply chain management, transparency, and accountability
▪ Domain 16: Threat and vulnerability management
This latest revision introduces three new domains from previous versions, namely, interoperability and portability (domain 12), mobile security (domain 13), as well as supply chain management (domain 14). Subsequently, the total numbers of controls have increased from 98, to now 138. As detailed in Chapter 2, the opportunity for potential end customers is to leverage STAR to identify providers that have adopted the CCM and have self-certified or utilized an independent third party. Having gone through over a year in review, according to Sean Cordero Co-Chair of the CCM Working Group: “CCM adoption gives cloud providers a manageable set of implementation ready controls that are mapped to global security standards. For customers, it acts a catalyst for dialogue about the security posture of their service providers, something that before the CCM existed was impossible. Keeping this balance in CCM v3 was a significant undertaking that could not have happened without the dedication of CSA member companies such as Microsoft, Salesforce, PwC, and the 120 + individual members who participated in the worldwide peer review. For their efforts and dedication we are grateful.”5
Consensus Assessments Initiative Questionnaire
Like the CCM, the CAIQ is also part of the CSA GRC stack. Initially released in October 2010, the assessment questionnaire was updated and released as version 1.1 in September 2011. Available in spreadsheet format, the questionnaire provides a series of questions in which the respondent can answer Yes or No, across multiple control groups that a cloud customer or auditor would likely ask of a provider. The control groups are as follows:
▪ Compliance
▪ Facility security
▪ Human resources security
▪ Information security
▪ Legal
▪ Operations management
▪ Risk management
▪ Release management
▪ Resiliency
▪ Security architecture.
Like the CCM, the CAIQ can be used by the providers as part of a self-assessment submission. Intended to be a companion to CSA Guidance and the CCM, the questionnaire allows potential end customers transparency and assurance as to the security posture of CSP.
External Certification Schemes/Standards
Many cloud providers are marketing the certifications and standards that their implementations have been certified or tested against. In addition to the CSA certification schemes, there are very many more that are used as a means to provide potential end customers assurance as to the security deployed by the provider. The following summarize many of these, however, the reader is reminded that this list is not exhaustive.
EuroCloud Star Audit
The EuroCloud Star Audit is governed by EuroCloud, an independent not-for-profit organization based out of Luxembourg. The certification process, however, does differ to alternate schemes with the manner in which certified companies demonstrate compliance. Many certification schemes support a binary response, for example, “we are certified” or “we are not certified.” With EuroCloud, those organizations that undertake the audit can articulate certification through EuroCloud stars, ranging from 1 to 5.
Evaluation of the service provider is based against a checklist that includes the following categories:
▪ Profile
▪ Contract and compliance
▪ Security and data privacy
▪ Operations and infrastructure
▪ Operations processes
At present, the completed assessments can be disclosed by the service provider, with a Website under preparation. The certification itself will be applicable for a 2-year period, and according to ENISA has been deployed across the EU.7
ISO/IEC 27001
Governed by the International Organization for Standardization (ISO), and the International Electrotechnical Commission (IEC), the origins of ISO/IEC 27001 certification goes back almost two decades. The origins go as far back as 1995, under the BS 7799 standard. The first revision was undertaken in 1998 with the first part that contained best practices. The standard was later adopted by the ISO, and renamed as ISO/IEC 17799. In 2005, the standard was revised and incorporated into the ISO 27000 series as ISO/IEC 27002.
The second part of BS 7799 was adopted by ISO in 2005 as ISO/IEC 27001. In 2013, both ISO/IEC 27001 and ISO 27002 have been revised and updated. The official title of ISO/IEC 27001 is “Information technology—Security techniques—Information security management systems (ISMS)—Requirements.” The development of the standard(s) within the ISO as well as IEC includes technical committees that are comprised of national bodies, as well other public/private sector international organizations. The publication of international standards requires approval from at least 75% of the national bodies that cast a vote.
Unlike other standards documented within this chapter, ISO 27001 is not developed specifically for cloud computing; it provides “requirements for establishing, implementing, maintaining and continuously improving an ISMS.”8 The 2005 revision focused on the Plan-Do-Check-Act model. However, the 2013 revision focused on measuring the effectiveness of the information security management system (ISMS) and introduced a new section on outsourcing. Another change is that the latest revision has 114 controls across 14 groups as opposed to 133 controls in 11 groups:
▪ A.5: Information security policies (2 controls)
▪ A.6: Organization of information security (7 controls)
▪ A.7: Human resource security—6 controls that are applied before, during, or after employment
▪ A.8: Asset management (10 controls)
▪ A.9: Access control (14 controls)
▪ A.10: Cryptography (2 controls)
▪ A.11: Physical and environmental security (15 controls)
▪ A.12: Operations security (14 controls)
▪ A.13: Communications security (7 controls)
▪ A.14: System acquisition, development, and maintenance (13 controls)
▪ A.15: Supplier relationships (5 controls)
▪ A.16: Information security incident management (7 controls)
▪ A.17: Information security aspects of business continuity management (4 controls)
▪ A.18: Compliance with internal requirements, such as policies, and with external requirements, such as laws (8 controls).9
Organizations that are seeking to demonstrate compliance against the standard have the opportunity to use a certification body that would be responsible for conducting audits to assess the compliance against the standard. A list of accredited certification bodies is maintained by the National Accreditation body within each country. Upon successful completion of the audit, the certification body certifies the ISMS. A detailed overview of the process is as follows10:
As expected, with the standard being the foundation for information security among organizations for such a long period, a number of providers have achieved certification against ISO 27001, particularly, as the standard will likely be used by potential customers, and will naturally be sought in prospective CSP. The challenge, however, may well be transparency, in particular the scope of the ISMS will be of critical concern. End customers will require visibility of the provider’s Statement of Applicability to determine which controls have been implemented. There may be circumstances where the provider may be unwilling to disclose this information citing that the information is potentially sensitive (as it relates to the security deployed by the provider). In these particular circumstances, end customers should consider the sensitivity of the data hosted by the provider, and whether the lack of transparency is indeed acceptable.
Payment Card Industry Data Security Standard
In 2004, 2004: The Payment Card Industry Security Standards Council was formed, and on December 15, 2004, these companies aligned their individual policies and released version 1.0 of the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS Council was founded by American Express, Discover Financial Services, JCB International, MasterCard, and Visa Inc. It was agreed among the founding members to “incorporate the PCI DSS as the technical requirements of each of their data security compliance programs.”11
Where a CSP is used within an environment where payment card data is stored, processed, or transmitted, PCI DSS will apply. This means that PCI DSS will “apply to that environment, and will typically involve validation of both the CSP’s infrastructure and the client’s usage of that environment.”12 Indeed this is much like the message reiterated throughout the book; while the work can be outsourced, the risk is not. Where payment card data is involved, “the allocation of responsibility between client and provider for managing security controls does not exempt a client from the responsibility of ensuring that their cardholder data is properly secured according to applicable PCI DSS requirements.” The level of responsibility applied to each party (the cloud customer and the CSP) is not fixed. What this means is that the end customer will need to ascertain what they are responsible for and that of the provider. CSP will generally assume greater responsibility as they assume greater elements of the end customers’ operations. This level of responsibility will be dependent on variables such as the type of cloud service being used, as well as other factors such as the scope of the operations outsourced. A summary of the PCI DSS requirements and the allocation of responsibility are included in the subsequent paragraphs, however, the reader is encouraged to review the “PCI DSS Cloud Computing Guidelines”13 for further details.
What the preceding information clearly demonstrates is that responsibility for meeting the requirements of PCI DSS will vary not only in terms of the model used, but also vary across providers. It is therefore imperative for the end customer to clearly define the various roles and responsibilities and ensure that these are not only included within formal contracts (e.g., using service-level agreements (SLAs)), but appropriate monitoring is in place to ensure the responsibilities owned by the provider are met.
Federal Information Security Management Act
In 2002, the U.S. President signed the E-Government Act recognizing the importance of Information Security “to the economic and national security interests of the United States.”14 This meant that every federal agency were required to “develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.”15 The Act itself sets out a series of high-level requirements with compliance mandatory for federal agencies within the United States. The “high-level security requirements” mandated by Federal Information Security Management Act (FISMA) are further specialized through Federal Information Processing & Standards (FIPS) and other more detailed standards, such as the National Institute of Standards and Technology (NIST) SCAP16; this is graphically depicted in Figure 6.2.9
“The National Institute of Standards and Technology (NIST) outlines nine steps toward compliance with FISMA:
1. Categorize the information to be protected.
2. Select minimum baseline controls.
3. Refine controls using a risk assessment procedure.
4. Document the controls in the system security plan.
5. Implement security controls in appropriate information systems.
6. Assess the effectiveness of the security controls once they have been implemented.
7. Determine agency-level risk to the mission or business case.
8. Authorize the information system for processing.
9. Monitor the security controls on a continuous basis.”17
From a cloud computing perspective, a number of providers have sought accreditation against FISMA which had already, for example, been “obtained by Google for its Apps service and by Microsoft for its cloud infrastructure and its BPOS-Federal service.”18 For potential cloud end customers that require FISMA compliance, they will need to pay particular attention to the designation applied to the provider; there are three allocated levels of threat: low, moderate, and high.
The Federal Risk and Authorization Management Program
Intended to provide a standardized approach for the assessment of CSP, the federal risk and authorization management program (FedRAMP) is a mandatory requirement for cloud deployments by U.S. federal agencies, as well as service models that operate at low and moderate risk impact. Introduced in 2011, the U.S. Federal Cloud Computing strategy implemented a “cloud first strategy”: “This policy is intended to accelerate the pace at which the government will realize the value of cloud computing by requiring agencies to evaluate safe, secure cloud computing options before making any new investments.”19 Key to this strategy will be the implementation of FedRAMP, which according to a memo published by the Executive Office of the President20:
“Each Executive department or agency shall:
▪ Use FedRAMP when conducting risk assessments, security authorizations, and granting ATOs for all Executive department or agency use of cloud services;
▪ Use the FedRAMP PMO process and the JABa-approved FedRAMP security authorization requirements as a baseline when initiating, reviewing, granting and revoking security authorizations for cloud services;
▪ Ensure applicable contracts appropriately require CSPs to comply with FedRAMP security authorization requirements.”
A FedRAMP Program Management Office (PMO) has been established to create the process by which stakeholders will adhere to the requirements of the program. In addition, the office will also develop contractual documentation that can be used by agencies in the negotiation with potential service providers, which includes standard contract language and SLAs. The requirement is for every department to utilize FedRAMP contracts appropriately, requiring CSPs to comply with FedRAMP security authorization requirements, as well as its use when conducting risk assessments. As a result, a number of CSP are marketing their services as ‘FedRAMP compliant’ in an effort to garner customers from U.S. federal agencies. The controls within FedRAMP itself are based on NIST SP800-53 (R3), however, there are additional controls that have been included which vary based on the impact level21:
| Impact Level | NIST Baseline Controls | Additional FedRAMP Controls | Total Controls Agreed by JAB for FedRAMP |
| Low | 115 | 1 | 116 |
| Moderate | 252 | 45 | 297 |
The additional controls are across multiple areas; however, the majority reside within access control (6) and system and communications protection (11). The following lists the broader control areas that FedRAMP is comprised of:
▪ Access control
▪ Awareness and training
▪ Audit and accountability
▪ Security assessment and authorization
▪ Configuration management
▪ Contingency planning
▪ Identification and authentication
▪ Incident response
▪ Media protection
▪ Physical and environmental protection
▪ Planning
▪ Personnel security
▪ Risk assessment
▪ System and services acquisition
▪ Systems and communications protection and
System and information integrity.
Once the CSP has made a FedRAMP application and the controls have been implemented, the next step in the process will be to work with an accredited Third-Party Assessment Organization (3PAO) to undertake an independent assessment. A list of accredited 3PAOs is available on the FedRAMP Website which also contains contact details, including a named individual nominated as Point of Contact. Becoming an accredited 3PAO requires an application to “meet both technical competence in security assessment of cloud systems and management requirements for organizations performing inspections.”22 The accreditation of 3PAOs is done through the American Association for Laboratory Accreditation which not only evaluates the technical competence of the applying organization, but also ensures their compliance against ISO/IEC 17020.
Federal agencies that are looking to leverage cloud services will have the opportunity to review the existing list of providers that have FedRAMP authorization at the following URL (correct at the time of writing): http://cloud.cio.gov/fedramp/cloud-systems.
Federal agencies will be expected to complete an inventory of CSP currently in use and identify those that are not FedRAMP compliant. The agency will then be expected to undertake a process to ensure that all providers achieve compliance. This may require noncompliant providers to undertake certification, in which case the agency will be expected to notify the FedRAMP PMO that the provider wishes to pursue the “Authority to Operate” with their agency. Further, if provisional authorization is required the agency is expected to track the application with the service provider’s effort to achieve certification.
In January 2014, it was reported that “Eleven vendors – including Akamai, Amazon Web Services, AT&T, Hewlett–Packard, IBM, Lockheed Martin, and Microsoft – are now authorized to operate cloud services for all or some federal agencies. A dozen more services are moving through the application process and more are in the pipeline, says FedRAMP director Maria Roat.”23 Further, the process for service providers can be particularly onerous: “It can take providers six to nine months to put the needed management disciplines and technical controls in place. Then begins the continuous monitoring, reporting, and remediation work that FedRAMP requires. For vendors unused to working in the government IT environment, the cost of entry is stiff… it would take between $25 million and $35 million in engineering and staffing costs for a commercial cloud service provider to meet the government’s demanding IT security standards.”24
Cloud Industry Forum Code of Practice
Established in 2009, the Cloud Industry Forum aims “to provide transparency through certification to a Code of Practice for credible online Cloud service providers and to assist end users in determining core information necessary to enable them to adopt these services.”25 Compliance against The Code of Practice is achieved either through annual self-certification, or the provider can seek independent certification through a certification body that has been approved by the Cloud Industry Forum. Those organizations that adopt the self-certified process will be authorized to use a “Certification Mark,” whereas those that have been certified via a certification body are authorized to use an “Independent Certification Mark.”
Within the code of practice, there exist a number of declarations that relate to security, as well as to the GRC stack of the Cloud Security Alliance:
▪ A.1.6. Security Control Transparency with the Cloud Security Alliance: Requests the providers to state whether they have completed the CSA Consensus Assessments Initiative Questionnaire.
▪ A.1.9. Existing Certifications (Optional): Allows the providers to define whether they have any other relevant certifications.
▪ A.2.6. Provisions for Information Security: The provider will detail the measures implemented for information security.
▪ A.2.7. Data Protection Provisions: To detail the geographies where data will or may be held during the length of the contact. This will also include a summary of the relevant data protection legislation and measures used to achieve compliance.
▪ A.2.8. Provisions for Service Continuity: The measures used to maintain continuity of the service.
▪ A.2.9. Provisions for Audit: Details the ability to conduct independent audits.
Potential end customers have the opportunity to visit the following URL (correct at the time of writing) to find a provider that has undergone certification: https://selfcert.cloudindustryforum.org/certification/.
This search facility provides both providers that have completed certification and those that are undergoing the certification. In addition, those organizations that have completed the certification process will have the scope of services that are covered by the code as well as the expiration date of the certificate. The code of practice is an excellent source for potential customers when identifying and engaging with a potential service provider. The scope of the certification goes beyond security, however, it does cover key questions that are likely to be part of the broader due diligence process.
IT-Grundschutz Certification
The IT-Grundschutz is a certification scheme that was established by the national security agency of Germany, known as the Federal Office for Information Security (BSI). The “goal of the Federal Office for Information Security (BSI) is to promote IT security in Germany.”26 Originally published in 1994 and updated in 2005, the IT-Grundschutz provides a methodology for the management of information security for an organization’s information assets. Certification will involve both an official ISO certificate against ISO 27001, but also an audit against the technical controls defined within IT-Grundschutz.
IT-Grundschutz is comprised of the following five parts:
▪ BSI Standard 100-1 Information Security Management Systems (ISMS): Based on ISO 27001 and 27002, the 100-1 standard defines the requirements of an ISMS, and how it can be implemented.
▪ BSI Standard 100-2 IT-Grundschutz Methodology: Focuses on how the ISMS can be implemented in practice, this includes the development of a policy.
▪ BSI Standard 100-3 Risk Analysis based on IT-Grundschutz: Includes the steps required to carry out a risk assessment, as well as how to determine which assets should be included.
▪ BSI-Standard 100-4: Business Continuity Management: As the name implies, the 100-4 standards details how to establish and manage BCP within the organization.
▪ IT-Grundschutz Catalogs: includes an overview and for specific threats to be placed in specific categories.
Although the aforementioned standards are not cloud specific, the Federal Office for Information Security (BSI) published a white paper entitled ‘Security Recommendations for Cloud Computing Providers’27 intended “to provide a basis for discussion between CSPs and cloud customers.” The paper is seen as the first step for the development of security within cloud computing environments, with further additions anticipated to be included in the IT-Grundschutz as modules. In particular, it is anticipated for BSI 100-2 to be “adjusted, particularly in the area of modeling complex, virtualised information networks.” Security recommendations within the paper are defined into three categories:
1. Category B: Basic for all CSPs.
2. Category C+: Includes additional requirements where high confidentiality is required.
3. Category A+: Includes additional requirements where high availability is required.
The white paper presents a series of security recommendations that are classified as to whether they apply to public and/or private clouds and whether the threat level is average or elevated for each implementation. Finally the recommendations are put into one of the three aforementioned categories (B, C+, or A+). An example of the security recommendations for network security is illustrated in Figure 6.3.
The white paper is a thoroughly comprehensive series of security recommendations, and the reader is encouraged to review the document particularly where high availability or confidentiality is required.
TUV Rheinland Certified
The TUV Rheinland certification allows CSP to demonstrate their security posture to potential customers through the Certified Cloud Service certificate. Certification is achieved through an audit that determines the implementation of the certificate requirements: stress testing against the architecture, check against the performance pledges within contracts/SLAs, as well as penetration testing for the technical detail checks. Upon successful completion of all of these measures, the provider is certified for a 3-year period which will be regularly checked.
According to ENISA; “TÜV Rheinland Certified Cloud Service is the most widely used and independent cloud service certification in Germany and becomes more and more relevant across Europe.”28 For end customers, a public site is available that supports searching for companies that have undergone the certification process and is available at (correct at the time of writing): http://www.certipedia.com/.
While every effort was made to provide as comprehensive a list of certification schemes as possible, what is clearly evident is that there are a multitude of additional available schemes that have not been detailed. This will include the likes of HIPAA, as well as other information security schemes. However, what the above demonstrates is that while end customers were previously forced to leverage schemes that were not developed specifically with cloud in mind, this is now changing. Equally while the number of schemes may be confusing, with overlap between most of the above, the good news is that all provide a degree of transparency which is imperative in furthering the adoption of ‘secure’ cloud computing. Also, as was inferred throughout this text, there exist many flavors of cloud computing with many providers certifying to win business in specific geographies and/or verticals. Therefore regardless of the industry the end customer is in, and the likely regulatory requirements they have to adhere to, chances are that a CSP meeting their needs will exist. Equally, many of these schemes also provide a central repository that allows potential customers to review and verify the certification status of providers in an easy and efficient manner.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.