Chapter 2
Selecting and Engaging with a Cloud Service Provider
Abstract
Selecting a cloud service provider will need to consider a number of key criteria, price being only one of these. This chapter will consider the available mechanisms to measure the security deployed by prospective providers.
Keywords
Assessment; Continuous monitoring; STAR initiative; Service level agreementThe cloud service provider that you selected has just gone out of business. A letter has arrived at your door from administrators of the provider warning you that unless you provided a large upfront cash payment by close of business today then the data center will close, oh and by the way, if you do not want to pay and simply get your data back, it will probably take up to four months!
This may sound like a hypothetical worst case scenario, but it is exactly the position customers of 2e2 recently found themselves in.1 Administrators were hoping to raise a total of £960,000, with smaller users expected to contribute £5000 each. Failure to meet the required total would likely prove devastating to many if not all customers:
We have received a number of requests from customers seeking to gain access to their data immediately. Unfortunately, the levels of data held in the companies’ datacentres are such that this process could take up to 16weeks and we will need to ensure that the integrity of third-party data and security is maintained.
Consider the impact this type of scenario can have not only on your business, but also on your career and credibility within your place of employment. After all, you did undergo appropriate due diligence did you not? There is no suggestion that 2e2 customers failed to undertake appropriate due diligence, and indeed the cause of the issue was financial and not as a result of a security-related incident. However, it is presented as a warning, that selecting and engaging with a cloud provider demands due diligence to satisfy not only appropriate regulatory bodies (where applicable), but also the internal organization, and in a worst case scenario the media and irate customers. This due diligence will likely include not only the security maturity of the provider, but also their financial viability (wherever possible), possible analysis into the directors of the company, etc. One option would be to adopt a modified Know Your Customer (KYC) principle adopted by financial institutions. The KYC controls typically include the following2:
▪ Collection and analysis of basis identity information.
▪ Name matching against lists of known parties.
▪ Determination of the customer’s risk in terms of propensity to commit money laundering, terrorist finance, or identity theft.
▪ Creation of an expectation of a customer’s transactional behavior.
▪ Monitoring of a customer’s transactions against their expected behavior and recorded profile as well as that of the customer’s peers.
While a like for like approach is unrealistic as this application is so very different to selecting a cloud provider, a comprehensive assessment is advisable as recommended by the Federal Financial Information Examination Council.3 In their 2012 statement, they stated that “Cloud computing may require more robust controls due to the nature of the service. When evaluating the feasibility of outsourcing to a cloud computing service provider, it is important to look beyond potential benefits and to perform a thorough due diligence and risk assessments of elements specific to that service.”3 Some of the steps that should be considered under the Know Your Cloud Service Provider process should include the following, according to a paper by Peak the Cloud entitled “Tips for Selecting Your Cloud Provider”4:
▪ Solid reputation: This will involve checking for references from the provider’s existing clients, and whether these implementations relate to the service prospective clients are considering. This should also include whether their implementations align with industry/geography where relevant.
▪ Best of breed technology partnerships: It is advised to determine whether the prospective provider has the appropriate partnerships with technology providers that align with the potential service.
▪ Financial stability and growth: This measure will determine the financial viability of the provider, and will ultimately determine on the willingness of the provider to discuss their financial state. This may be feasible if the accounts are publicly accessible, and will allow potential customers to determine if the provider has a history of stability and growth.
▪ Enterprise-grade data centers and state-of-the-art equipment: Where possible the potential customer should ensure that the infrastructure is capable of supporting the overall business. This will be a difficult measure to ascertain as the right to audit is generally unavailable.
▪ Compliance, availability, and performance: These measures will be covered in further detail later in this chapter.
Many of these tips address those that relate to the business viability and as such are out of scope of this book, with security and privacy considerations the focus of this publication. Further, dependent on the service sought not all of these measures will be required as the level of due diligence should be commensurate with the level of risk the organization is willing to tolerate. For example, where a provider is sought to host commercially sensitive data then the level of due diligence should be higher than if noncommercially sensitive data are being hosted. There is no magic formula with regards to the level of due diligence that should be undertaken, nor is there any specific methodology that must be followed, although certain frameworks for regulated data may either be advisable or required (for example, the Privacy Impact Assessment for personal data). Determining these factors will be entirely subjective; therefore, the following should be used as guidance and tailored according to the business (and business function).
Security, Trust and Assurance Repository Initiative
One option afforded to potential end customers is to engage with each and every potential cloud service provider to determine the security controls implemented. In fact, in discussions with many providers today this appears to be the default method used by potential customers. Although such a method is likely to receive a response, it is an incredibly inefficient method for both provider and customer. For this reason, the Cloud Security Alliance launched the Security, Trust and Assurance Repository (STAR) in 2011.
As discussed in Chapter 1, one of the greatest challenges associated with cloud computing is the lack of transparency regarding the level of security deployed by the provider. In an effort to address this issue, STAR was launched to provide a central repository where potential customers can freely access to determine the level of security deployed by providers it allows. This provides a level of transparency that historically would have required more than likely multiple e-mails/calls to each and every provider under consideration. Now potential customers not only have a single place to go to understand the security employed by multiple providers, it also allows for comparisons to be made providers therefore improving assurance in the cloud.
The registry itself is based on three layers:
1. Self-assessment: The first layer publishes the result of the Consensus Assessment Initiative Questionnaire (CAIQ) and/or the Cloud Controls Matrix (CCM). As the name suggests, this particular layer has been filled out and completed by the provider. Therefore, entries on this layer provide less assurance and transparency than subsequent layers. Please note that from March 2014, providers were given the option of using either CCM v1.4 or CCM v3. The opportunity to use both standards will remain until February 2015, whereupon all providers will be assessed against CCM v3.
2. Third-party assessment-based certification: The second layer publishes the results of an assessment undertaken by a third party on the cloud service provider against the CCM and International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) 27001 (please refer to Chapter 6 for more details on ISO/IEC standards), or American Institute of Certified Public Accountants (AICPA) Service Organization Control (SOC) 2. Results within this layer provide a greater level of assurance, in that they are verified by a third party.
3. Continuous monitoring-based certification: Results within this layer are published in a continuous fashion. While previous layers would update the registry based on the audit or certification cycle (usually annually) of the provider, continuous monitoring leverages the Cloud Trust Protocol (CTP) to update as the name suggests, continuously! As the results are provided even outside of annual audits, end customers are given the greatest transparency and assurance regarding the security maturity of the provider. Please refer to Chapter 6 for more detail on CTP.
A review of the various layers would suggest to the end customer that it would always be prudent to use providers that fall into the third category. However, as mentioned earlier in the chapter, the level of due diligence should be commensurate with the level of risk an organization is willing to tolerate. Equally, this level of risk will depend on the value of what is being hosted with a third party. So the hosting of nonsensitive data could well suffice with providers that only offer self-assessment, but the hosting of sensitive data will likely require a greater level of assurance.
Accessing the STAR Registry
The STAR registry is currently located at the following URL: https://cloudsecurityalliance.org/star/.
A snapshot of the repository is included under Figure 2.1. As detailed earlier, the entries within the repository provides the potential end customer with a simple interface that includes the name of the provider, URL, an overview of the company, and when the submission was made.
There also includes details of the type of submission made; as the examples in Figure 2.1 demonstrate, the two providers have undertaken a self-assessment as well as certification. At present, there are four methodologies that providers can use to assure end customers; these methodologies, however, fall into the three levels described previously. Certification and attestation both fall within the second level:
Level One
▪ STAR self-assessment: There exist a large number of cloud providers that have made self-assessed contributions to the STAR registry. This includes contributions based on the CAIQ, or alternatively the CCM. Both are referenced in this chapter, but with further detail included in Chapter 6.
Level Two
▪ STAR certification: For end customers looking for additional assurance, the opportunity exists to utilize level-two submissions where the security of the provider has been independently verified by a third party. Of the two options available under level two, STAR certification leverages the ISO/IEC 27001:2005 standard, in conjunction with the Cloud Security Alliance (CSA) CCM. As the ISO standard has been first published in 2005, ISO/IEC 27001:2005 replaces BS 7799-2:2002, which contains a total of 134 controls that support 39 control objectives. Each of these controls and their corresponding objectives are divided into 11 domains (as depicted in Table 2.1). The standard has long been used by organizations looking to develop a formal security management program (Information Security Management System (ISMS)), and as such by incorporating the standard into STAR allows providers to leverage existing investments when demonstrating the security deployed to potential customers.
Table 2.1
| Control Domain | Objectives | Controls |
| Security policy | 1 | 2 |
| Organization of information security | 2 | 11 |
| Asset management | 2 | 5 |
| Human resources security | 3 | 9 |
| Physical and environmental security | 2 | 13 |
| Communication and operational management | 10 | 33 |
| Access control | 7 | 25 |
| Systems development and maintenance | 6 | 16 |
| Information security and incident management | 2 | 5 |
| Business continuity plan | 1 | 5 |
| Compliance | 3 | 10 |
| 39 | 134 |
The third-party assessment can only be carried out by organizations that are certified by the Cloud Security Alliance. The assessment itself will indicate a score that indicates the management capability against the domains of the Controls Matrix, which will ultimately result in the allocation of a level that will either be classed as No, Bronze, Silver, or Gold.
▪ Attestation: While STAR certification focused on ISO/IEC 27001:2005 combined with the CCM as the framework by which the security is measured, attestation utilizes Type 2 SOC attestations supplemented with the CCM. Many readers are likely to be familiar with Statement on Auditing Standards (SAS) 70 auditing standard that preceded Statement on Standards for Attestation Engagements (SSAE) 16. Issued by the AICPA, the SSAE 16 provided three SOC reports for Certified Public Accountants (CPAs) to report on the controls at a service organization. An assessment by the CSA on the standard was conducted and published in the report entitled “CSA Position Paper on AICPA Service Organization Control Reports.”5 The assessment found “for most cloud providers, a type 2 SOC 2 attestation examination conducted in accordance with AT section 101 of the AICPA attestation standards is likely to meet the assurance and reporting needs of the majority of users of cloud services, when the criteria for the engagement are supplemented by the criteria in the CSA CCM. AT 101 provides the following key strengths for the cloud industry’s consideration:
▪ Allows for immediate adoption of the CCM as additional criteria and the flexibility to update the criteria as technology and market requirements change.
▪ Provides for robust reporting on the service provider’s description of its system, and on the service provider’s controls, including a description of the service auditor’s tests of controls in a format very similar to the now obsolete SAS 70 reporting format, and current SSAE 16 (SOC 1) reporting, thereby facilitating market acceptance.”
As with STAR certification, the benefit for providers is to leverage existing investment that they may have had with the AICPA SSAE 16 standard. By supplementing with the CCM (as with those that used ISO/IEC 27001:2005), the provider is able to demonstrate their security to potential customers without adoption of an entirely new framework. Moreover, for potential customers looking to migrate to cloud services, they can be assured that the framework used to assess security of potential providers is tailored specifically to cloud services.
Level Three
▪ Continuous: As previously mentioned, those providers that provide assurance via continuous methodology utilizing CloudAudit will be classified as continuous. This level is seen as providing the highest level of assurance because as the name implies it is continuous and not based on a point in time assessment. At present, this particular level is not available, and is expected to be available in 2015.
Engaging with the Cloud Service Provider
Once the decision is made of which cloud provider to use, the challenge for the end customer will be ensure that the security controls are clearly defined. Clearly defining these requirements within a formal contract is imperative, as it clearly delineates the responsibilities expected of the provider. Further, having these clearly defined will be important in the event the end customer feels the provider has not fulfilled their obligations, and should further action be required.
Service Level Agreements
The typical approach for organizations to define the requirements they expect of the outsourced provider will be to leverage a series of service level agreements (SLAs). According to the European Commission’s publication “Cloud Computing Service Level Agreements,”6 an SLA is defined as
A Service Level Agreement (SLA) is a formal, negotiated document that defines (or attempts to define) in quantitative (and perhaps qualitative) terms the service being offered to a Customer. Any metrics included in a SLA should be capable of being measured on a regular basis and the SLA should record by whom
These SLAs are likely to incorporate many more requirements than security, but should be detailed to define not only the expectations, but also how monitoring of these SLAs are achieved. According to the European Network Information Security Agency (ENISA) in their 2012 report entitled “Procure Secure, A Guide to Monitoring of Security Service Levels in Cloud Contracts,”7 there is a difference in the ability of the end customer to negotiate SLAs with the provider: “It is important to differentiate between small projects, in which the customer will simply make a choice between different types of service and their SLAs (service level agreements) offered on the market, and large projects, where the customer may be in a position to negotiate with providers about the kind of service or SLA required.”
Regardless of whether the end customer has the ability to negotiate service levels, as a minimum it is important to understand how the security controls will be deployed and monitored. Of course, the level of due diligence undertaken will be dependent on the value of data being hosted/processed by the provider. The guidance provided within the ENISA guidance provides “the most relevant parameters which can be practically monitored”; these are defined as follows:
1. Service availability.
2. Incident response.
3. Service elasticity and load tolerance.
4. Data lifecycle management.
5. Technical compliance and vulnerability management.
6. Change management.
7. Data isolation.
8. Log management and forensics.
It may not be necessary for the end customer to define, or even review, all of the above service levels defined by the provider. This will be entirely dependent on the type of service being sought; for example, within an IaaS environment, the end customer will likely be responsible for ensuring security patches are deployed on the operating system and applications. Subsequently, it is recommended to ensure that the scope of the project and customer expectations are clearly defined before any provider is engaged. This will allow any potential negotiation to be concluded more effectively, and where negotiation is not possible for the review of services to be more effective. It is recommended for the ENISA guidance to be reviewed to obtain further detail on the aforementioned parameters. Of course, that is the recommendation, and all cloud customers follow the recommended guidance, do they not?
Sadly, the reality is that many cloud customers fail to undertake the appropriate level of due diligence when defining the security service levels they expect from their providers. In a survey conducted by ENISA, and subsequently published in “Survey and analysis of security parameters in cloud SLAs across the European public sector”8 the results revealed that, while availability is often covered, many security parameters are rarely covered. This survey requested content from information technology (IT) officers within the European public sector, and therefore the results reflect the implementation of cloud or IT projects for the European public sector.
The following are the key findings:
▪ Governance frameworks/security standards: While ISO 2700x and Information Technology Infrastructure Library (ITIL) were the frameworks/standards used by the majority of end customers, ensuring alignment with their third-party providers is rarely done. For example, only 22% of respondents stated that their IT providers are obliged to adhere to the same standards. Indeed, almost one in five (19%) of providers were not obliged to comply with their customers. Although it is suggested that this may undermine the ISMS of the end customer, not having consistency will likely increase the cost of managing (e.g., hiring subject matter experts to understand the standards used by the provider), as well as the efficiency of managing security.
▪ Availability: The majority of SLAs (50%) referring to availability ensures that the “service is reachable by all clients”; however, 1 in 10 have not defined availability. This is rather surprising as this particular requirement would be the easiest to measure and would be an important requirement regardless of the type of service provisioned. This would explain why just over the same percentage (11%) of respondents did not know what the requirements actually were. The majority of SLAs (37%) referring to availability dictated two nines or 99%, which would suggest that the majority of externally provisioned services were not particularly critical (only 8% required four nines or 99.99%). Equally, the majority of providers (70%) are obliged to report downtime within a given timeframe. Please see Table 2.2 for the percentage calculation, with the results from the ENISA survey.
▪ Security provisioning: While there is a degree of consistency with most respondents defining requirements for availability, security is less well defined. To an extent, this is not hugely surprising, as the services that are provisioned externally are not particularly critical (with only 8% dictating very high availability), but nonetheless the level of disparity among respondents is still surprising. Figure 2.2 shows the disparity regarding the components explicitly defined with the SLA.
▪ Security incidents: One example of a requirement that is not defined as consistently as availability is security incidents. A total of 42% of respondents commented that SLAs did not include a classification of incidents, and a further 32% stated they only briefly commented on how the schema works. Although other categories are entirely subjective in their necessity (e.g., take cryptography is unlikely to be required when the data managed by the third party is not sensitive), there is no question that the need to have consistency regarding security incidents will be important to all customers. In addition, only half of respondents confirmed that providers were obliged to notify of security incidents within a given timeframe, and in only 43% of cases did the SLAs specify a recovery time for incidents where the provider faced penalties for not recovering within the time specified. To put this into perspective, less than half of providers were obliged to notify customers that their data/systems had experienced a security incident and even if they did the provider was not financially incentivized to recover in the time specified! This sounds remarkable, and one could easily point the finger at the provider, but sadly this demonstrates that, although the customer is ultimately responsible for ensuring such measures are clearly defined, they are on the whole failing to do so. This could of course be because the service that is being provisioned is of so little value to the end customer that any form of interruption is acceptable (however, reviewing the responses regarding availability we know this is not entirely the case).
▪ Service levels: Building upon the lack of penalties applied to providers in the event of a security incident, the survey revealed that almost one in four end customers do not define penalties in the event the provider fails to meet service levels.
Message from Said Tabet (CSA Co-Chair of the SLA Working Group), “Within the CSA we recognize the value in SLAs as they relate to cloud computing. We are therefore conducting a lot of work within this space, and the reader is encouraged to understand the areas of focus for our working group.”
When engaging with a cloud provider, it is recommended for the SLAs to reflect the security requirements of the end customer. The level of flexibility afforded to the end customer will be limited, according to the Cloud Buyer’s Guide9: “A typical cloud contract will have little flexibility in negotiating terms and penalties — the only real option in a true cloud implementation will be a credit for downtime, with no enhancements for loss of business critical functionality.” Subsequently, undertaking the appropriate due diligence in determining the security controls provided is imperative, this should be followed up with the SLAs, which according to the buyers guide “The single most important aspect of any liability and warranty statement revolves around breach of security and loss of personal data. The average cost per user of a data breach is approximately $215, so the liability language in the contract should ensure that the insurance coverage provided by the provider could cover the total fees for a breach where the provider is at fault. This liability clause must ensure that the provider WILL and MUST allow for a third party to perform a root cause analysis and be bound by the findings of the party. This may need to be negotiated prior to the execution of a contract.”
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.