1 Introduction

This chapter highlights the impediments to cloud adoption arising from cloud security and describes the establishment of a framework to address the adoption issue in general and the design of a multi-tiered cloud security model to help users to better appreciate the security provisioning by cloud service providers (CSPs).

Cloud computing shifts much of the control over data and operations from the user organization to CSPs, much in the same way organizations entrust their Information Technology (IT) operations (or part of) to outsourcing companies. In addition to the usual challenges in delivering secure IT services, cloud computing presents an elevated level of risk in outsourcing to a third party as the computing environment becomes more complex and dynamic to manage.

Cloud computing has introduced key enabling technologies such as hypervisors and virtual machines to create a very agile and dynamic computing environment. These technologies however, also bring about a host of challenges and risks. Additionally, the massive sharing of infrastructure and computing resources in a multi-tenanted environment, especially with users spanning different organizations and security needs, creates a “shared virtual environment” where users/organizations are no longer clearly divided by physical server racks and separate networks. New users in cloud computing can be easily changed or created by initializing online additional virtual machines and networks. Inside a cloud, it is difficult to physically locate where the data is stored and how it is segregated. This lack of visibility, and thus ability to audit and verify, pose a number of security and compliance issues.

2 The problem

According to IDC (IDC, 2009), cloud security is the Number One concern cited by IT managers when they consider cloud deployments. Another study (Launchpad, 2009) conducted by Launchpad Europe, a company that helps emerging firms with global business expansion, found that nearly half of organizations say they have no plans to use any cloud computing technologies in the next year, citing security concerns as the primary reason.

Every industry has its own unique characteristics and concern. The tolerance level of security risk differs from sector to sector. For example, the banking community is extremely concerned with the risk exposure of their customer information stored in cloud. They may take a more cautious step and a longer time to move their mission critical banking applications to the cloud.

Other industries may feel that the benefits outweigh the potential risk and may be more forthcoming in adopting cloud. CSPs today provision security to a much better degree that small- or medium-sized enterprises (SMEs) could not achieve by themselves. In the past, the cost and complexity to ensure such security meant that it used to be only accessible to large enterprises. Also many corporate-grade applications (e.g., CRM) are available to these SMEs. Thus, the security challenge of cloud computing needs to be viewed in this perspective, relative to what we have now and matching of provisions by the CSPs to users’ needs. The crux of issue in cloud adoption is therefore, devising a security framework that provides visibility and clarity of security provisions of the CSPs to facilitate matching with users’ needs.

3 Holistic approach

Security (or its lack thereof) is not an insurmountable obstacle to cloud computing adoption. It is important to understand that the concern of cloud security arises from various sources, ranging from a lack of understanding to unavailability of common standards for assessment. We therefore need to take a multi-pronged holistic approach in the framework to tackle adoption issues relating to cloud security, as depicted in Figure 1.

4 Why develop cloud security standards and guidelines

Today, there are no cloud standards and guidelines currently available that have been widely accepted and adopted by CSPs and cloud users. A survey of current initiatives in cloud security (see Section 5) reveals that none of the guidelines can be directly adopted without significant changes.

5 Related work

There are several initiatives undertaken worldwide to address cloud security issues, noticeably in the United States and Europe. In the United States and Europe, industry players are working together to tackle these challenges.

The Cloud Security Alliance (CSA) security guidelines are high-level recommendations and are not auditable standards. CSA’s Governance, Risk Management and Compliance (GRC) Stack guidelines provide a set of questions and requirements which is difficult for users to evaluate and assess the detailed responses for adequacy of the security provisions by CSPs (CSA, 2010).

In Europe, ENISA, a 24-member strong consortium of service providers, vendors, government organizations, and consultants together define common assurance metrics to allow businesses to compare the security standards of CSPs. These guidelines provide a set of questions and requirements that the users can ask CSPs to assure themselves that they are sufficiently protecting the information entrusted to them. The guidelines and assurance metrics document does not provide a standard response format for the CSPs, so detailed responses are in a free-text format which makes it difficult for users to evaluate and assess the adequacy of the security provisions by CSPs (ENISA, 2009a,b).

The FedRAMP (Federal Risk and Authorization Management Program) was established to provide a standard approach to assessing and authorizing cloud services. Based on an elaborate Federal Information Security Management Act (FISMA) framework, FedRAMP is however, specifically designed for use by the US federal government. It is not a national standard for all industries and sectors of economy (FedRAMP, 2014).

SAS70 was created by the American Institute of Certified Public Accountants in 1992. It was originally intended to review the controls in service providers for material effect on the annual financial statements. SAS70 is narrow in scope and not a comprehensive security framework when compared with ISO27001 (ISO/IEC, 27001:2005). The rise of cloud computing pushes CSPs to adapt the report to auditing controls in cloud service provisioning. As the security requirements and controls are self-defined by CSPs, the onus is on the cloud user to determine if these self-defined controls are adequate to meet his security needs (SAS70, 1992).

However, the current ISO27001 (ISO/IEC, 27001:2005) is not cloud specific. It establishes a generic Information Security Management System. The Japanese Industrial Standards Committee has proposed to ISO/IEC to establish guidelines for the use of cloud computing services. This new initiative (ISO/IEC JTC1/SC 27) would take at least another 3 years or so to develop into an international standard or technical report.

The above notwithstanding, it is important to establish necessary cloud standards and guidelines to guide the security provisioning by CSPs, as a step toward addressing a major impediment in cloud adoption. While the CSA GRC stack, ENISA and FISMA/FedRAMP standards and guidelines are not readily suitable for use, they serve as good references and inputs to our own standards development work.

6 Design considerations of multitiered cloud security

As the tolerance level of security risk differs from sector to sector, one solution to address such immediate security issues arising from cloud computing is to provide a multi-tiered model satisfying security needs of different cloud user groups; it may take a form similar to the well-known tiered service model in data center offerings (Uptime, 2013). This multi-tiered model covers users (including SMEs) with basic requirements to one that needs high confidentiality and high availability such as FSI. The tiered model must be able cover and differentiate between CSPs offering significant customization/private cloud and utility providers merging more features and capabilities with a less flexible model/public cloud.

These guidelines highlight the key security areas and associated controls to be addressed arising from the new cloud computing environment. These controls are defined to address or mitigate the new or elevated risks identified.

Some of the key design considerations are:

(a) Different levels of control that correspond to different levels of security requirements will have to be specified for each tier. Each higher cloud security tier builds upon lower tier, either with additional security requirements or more stringent controls and/or audit checks.

(b) To manage the scope and avoid duplication of work, such guidelines do not replace but complement and leverage on existing noncloud-specific security standards. Indeed the MTCS uses ISO27001:2005 as its foundation. It is important to provide CSPs a familiar basis to embark upon to attain MTCS certification.

(c) To consider riding on existing relevant standards and guidelines by including these as part of the control requirements, we need to consider the impact of direct dependencies which we are unable to influence or control. After careful evaluation, the decision was to make MTCS as self-contained as possible; this standard will include both implementation guides and necessary audit procedures.

(d) Other relevant standards, guidelines, and reference documents considered include Technical Reference 30 (TR30, 2012), Technical Reference 31 (TR31, 2012), CSA Cloud Computing Matrix (CSA, 2010), Payment Card Industry Data Security Standard (PCI, 2010), European Union Agency for Network & Information Security guidelines (ENISA, 2009a,b), National Institute of Standards & Technology SP 800 series (NIST, 2007–2013), and Technology Risk Management from Monetary Authority of Singapore (MAS, 2013).

(e) The number of tiers should not be so many that a cloud user would have difficulty understanding. The purpose of each tier should be intuitive to the cloud user. The eventual decision to have three tiers is arrived at after taking into account the focus group feedback received from cloud users and CSPs.

(f) The three tiers are so designed to cover different security needs of various cloud users; from baseline requirements of general SMEs through needs of most enterprises (protection of sensitive business information) to stringent demand of the regulated industries (high availability/reliability and resiliency plus better customers isolation and data segregation).

(g) While cloud service models like Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) have been defined (for example, by the National Institute of Standards & Technology (NIST, 2011), their implementations vary greatly across CSPs. Thus CSPs may scope out only different security controls that are applicable and relevant to their implementation of the service model. As such, we avoid associating specific security controls with each service model.

(h) Arising from the above point on not associating cloud service model with prespecified security controls is the issue of how each service model can be certified, given that each may be delivered by a distinct and separate commercial entity. For example, a straightforward solution is to require a PaaS (or an SaaS) seeking MTCS certification at Level x to be hosted on an IaaS that is already MTCS certified at Level y and ensuring that the y ≥ x.

7 Benefits to stakeholders

The benefits of MTCS to the four major stakeholders in cloud computing are as follows.

• CSPs: It helps CSPs to better meet the security needs of specific segments of cloud users. Adherence to such industry best practices removes doubts, uncertainties, and thus builds trust with the users. This not only cuts down the client engagement time and sales cycle but also minimizes or avoids future disputes with cloud users as the mismatch of security needs surfaces much later.

• Cloud users: Currently, it is a time-consuming exercise for the cloud users to carry out proper due diligence to source for the right CSP with appropriate security provisions. Many cloud users or companies may not even have the necessary technical expertise to carry out such an evaluation adequately. Cloud users, given such a yardstick, are able to validate controls and thus have assurance that their applications and data are protected. It also facilitates comparison of the security provisions of CSPs making it easier to identify the right CSP and resulting in faster cloud deployment.

• Auditors and regulators: These major stakeholders are able to use the guidelines to interpret security requirements consistently when auditing CSPs/users. Otherwise, the audit results may vary subject to the interpretation by different auditors/regulators and unnecessary disputes with the CSPs and/or cloud users. This saves time and effort in auditing and achieves compliance faster.

8 MTCS standards

The MTCS standards are built upon the international standard, ISO27001:2005 as its base. Many of the controls are being interpreted under the cloud computing environment and new cloud related/specific controls are then added as necessary. The standards are meant to be general and applicable to all sectors and industries even though it is designed to have multiple security levels. Those sector-specific controls such as use of special hardware or equipment or specific sectorial practices are being excluded. For the standards to be adopted in specific sectors or industries, additional industry specific standards and controls would have to be applied as depicted in Figure 2.

The design of tiers in MTCS standards is based on feedback from numerous focus groups comprising CSPs and cloud users from industry. It is structured according to usage types, sensitivity of data, and types of applications being hosted. The base tier, Level 1, has minimal controls, designed to host nonbusiness critical applications and nonsensitive data. Level 2 is focused on data protection, catered for more critical business applications and data, covering majority of the usages. The top tier is most stringent, oriented toward use by regulated industries, taking the common security requirements across such industries for critical applications with sensitive information as shown in Figure 3.

Level 2 adds new key security controls in “Data Governance” (24),¹ “Cloud Services Administration” (16), and “Tenancy & Customer Isolation” (16), while Level 3 adds new key security controls in “Operations” (16), “Business Continuity Planning & Disaster Recovery” (7), and “Tenancy & Customer Isolation” (11) (Figure 4).

While multitenancy introduces additional risks to cloud users, cloud computing risks overlap with other IT delivery models. These include risks associated with access, infrastructure, operations and governance. This standard breaks those risks into six categories as outlined in Figure 5. They are broadly grouped into two as follows:

• The core information security

• The cloud-specific information security

“Cloud Governance” covers generic issues ranging from management of information security, incidents, risks, and information assets but interpreted under cloud environment. “Cloud Infrastructure Security” specifies requirements of the underlying cloud infrastructure to ensure proper tracking, configuration, testing, monitoring, systems and services management, while “Cloud Operations Management” entails environment security, secured operations, management of changes to cloud infrastructure, and prevention of disruption to cloud services.

“Cloud Services Administration” ensures enforcement of policies, standards and procedures relating to creation, maintenance, and removal of privilege accounts used for managing cloud services and supporting networks. “Cloud User Access,” on the other hand, looks into securing user accounts to restrict access and safeguards user credentials to prevent unauthorized access. Last but not least, “Tenancy & Customer Isolation” dwells into issues dealing with multitenancy, data segregation, supporting infrastructure segmentation, network protection, virtualization risks (TR30, 2012), and storage area network.

9 Self-disclosure

A unique feature of MTCS is its spirit of building trust through transparency. Besides security, a self-disclosure requirement on their service-oriented parameters has been introduced. CSPs are required, as part of the certification process, to complete a self-disclosure form (see Section 5 and Annex A of MTCS, 2013) on key characteristics of their services such as legal and compliance, data control, performance, service elasticity, and support. Such disclosure enables potential cloud services buyers to better understand the differences among CSPs and evaluate more holistically how those service parameters may impact their needs beyond security requirements. See Figure 6 for a listing of the service parameters.

10 Certification scheme

The certification of a CSP is valid for 3 years. A yearly surveillance audit needs to be conducted by qualified assessors for MTCS certification. Such assessors are existing accredited certification bodies for ISO27001, with at least 3 years of relevant audit experience (e.g., ISO27001) and cloud computing knowledge (e.g., CSA Certificate of Cloud Security Knowledge) certified in near future.

11 Status

All CSP applicants must complete self-disclosure and prepare Statement of Applicability (SoA). They must agree to have their certification, SoA, and self-disclosure information made publicly available on a CSP Registry. The registry will also provide information on performance and availability of CSPs.

The development of MTCS started in 2011 under the auspices of the Singapore IT Standards Committee (ITSC) by a working group comprising representatives from industry. After 18 months of development, MTCS was approved as a Singapore Standard by ITSC Council in August 2013, following two rounds of 2-month public comments on the draft standards that elicited more than 350 comments from both local and foreign CSPs and users.

12 Deployment

The standards are now in active deployment phase since its official launch in November 2013. One way to deploy MTCS is to find a “lead user” such as the public sector or more “cloud ready” enterprises to pave the ways for its adoption. These early adopters will lead and demonstrate to other sectors that are more cautious and risk averse, especially those sectors that are regulated such as healthcare and financial. The regulated sectors can be in the next phase when exemplary deployments are established and environment is conducive and ready.

As of April 2014, MTCS certification has been made a mandatory requirement for the public cloud services bulk tender that seeks to qualify IaaS, PaaS, and SaaS on a shortlist for procurement by government agencies in Singapore. Hitherto, more than 10 IaaS, PaaS, and SaaS have been MTCS certified.

13 Harmonization

To enhance recognition of MTCS beyond Singapore, we have embarked on cross-certification (or harmonization) of MTCS with other international frameworks such as ISO27001 and CSA’s Open Certification Framework (OCF)². This minimizes the effort needed for CSPs certified to those international standards to gain MTCS certification and vice versa. It also benefits MTCS-certified CSPs with regional business to be recognized globally.

For each direction (represented by an arrow in Figure 7), a set of three documents have been developed; these are (a) Gap Analysis report; (b) Implementation Guide; and (c) Audit Checklist. Hence, four sets of such documents exist for the following:

(a) ISO27001:2005 to MTCS

(b) MTCS to ISO27001:2013

(c) CSA OCF to MTCS

(d) MTCS to CSA OCF

As an example, a systematic three-step approach is taken to map detailed requirements in ISO27001:2005 to corresponding requirements in MTCS.

(a) Mapping of control areas

(b) Mapping of specific requirements in each control area

(c) Mapping details of each requirement

The table in Figure 8 provides a summary of the gaps analysis of the mapping from ISO27001:2005 to MTCS. As MTCS control requirements are more specific and detailed, the percentage of matched MTCS clauses is only around 40% (referring to the number of matched MTCS clauses at Level 2 which is 179 out of a total of 449). As one progresses from the low to high tiers, the percentage of matched MTCS clauses from Level 1 to Level 3 drops from 45% to 37%.

Understandably, the key gaps are found in the areas of cloud-specific controls such as “Tenancy & Customer Isolation,” “Cloud Service Administration,” and “Cloud User Access” besides other core controls like “Data Governance,” “Infrastructure Security,” and “Operations Management.”

In the reverse direction, the table in Figure 9 provides a summary of gaps analysis of the mapping from MTCS to ISO27001:2013. The 2013 edition of the ISO27001 was published in September 2013, at about the same time as MTCS SS584:2013. As expected, the MTCS gaps with ISO27001:2013 are minimal around 10% (with reference to the number of gaps at Level 2 which is 26 out of 254). The gaps are found mainly in the area of “Performance Evaluation” of ISMS which is the new emphasis in the 2013 edition.

14 Future work

Besides harmonizing MTCS with other international frameworks, alignment of MTCS standards with various regulated industries (such as healthcare and financial sectors) is in the plan for next phase of deployment.

15 Conclusion

MTCS standards are the world’s first cloud security standards that feature multiple tiers. It is aimed at spurring the adoption of cloud computing across industries by providing greater clarity on the level of security offered by different CSPs. The standards are supplemented with a self-disclosure requirement on service-oriented information that is normally included in Service Level Agreement, giving potential cloud buyers a comprehensive tool to compare and evaluate the cloud service offerings across multiple CSPs beyond just cloud security.