2.1 Perspective 1: essential characteristics

Essentially, cloud computing offers the following characteristics as defined by NIST (NIST, 2011):

• On-demand self-service: Consumers are able to help themselves and decide which services to subscribe to, and how much to invest—all at the swipe of a credit card or using an online payment system. An IT department can now quickly purchase more resources on-demand to cater to sudden spikes in user load.

• Ubiquitous network access: Cloud services hinge on the Internet’s infrastructure, and as such provide a ubiquitous availability of services as long as there is an Internet connection. An USA-based executive can perform his roles during business travel, accessing his company’s online resources hosted in Ireland via the Internet connection in Singapore.

• Resource pooling: The combined computational power of large amounts of physical and virtual servers provides a cost-effective pooling of resources. Multitenancy solutions have enabled several organizations to share the same cloud computing resources without worrying about data spilling into each other’s logical boundaries.

• Rapid elasticity: Cloud services leverage on technologies such as server and storage virtualization to rapidly meet the rise and fall of user load and service demand. A newly launched business expecting 10,000 customers will be able to handle an unexpected load of 1 million customers without worrying about the need to purchase or set up new servers in short notice. Elasticity also improves the utilization of the cloud resources.

• Measured service with pay-per-use: Given the above characteristics, it works for both service providers and consumers to have an easy-to-measure payment scheme mimicking the power utilities and cable television model—pay-per-use. At the appropriate price point, pay-per-use has the potential to alleviate the need for forecasting and planning of resources, and reduce wastage of overheads.

The eagle-eyed reader will observe that the above five points do not point to a new technology paradigm, but an Internet-empowered, high-utilization business concept that simply works.

It replaces the awkwardness of predecessor technologies, such as utility computing and grid computing, as it comes with an easy-to-implement and easy-to-understand business and revenue model. Cloud also reduces the expectations on businesses to forecast demand correctly—which like weather forecasting, is rarely achieved successfully.

Currently, most stakeholders reference the NIST Definition of Cloud Computing (NIST, 2011). Recently, ISO/IEC 17788 (Information technology—Cloud computing—Overview and vocabulary) started defining the cloud computing definitions, but the uptake of the fresh set of definitions remains to be seen.

2.2 Perspective 2: layers and scope

With the characteristics, many cloud services are often categories by their “layers” (NIST, 2011):

• Applications of Software-as-a-Service (SaaS): Highly scalable software services such as e-mail software, accounting software, software engineering and deployment tools, and Web site creation tools. Examples include Outlook.com, Gmail, Salesforce.com, etc.

• Applications of Platform-as-a-Service (PaaS): Elastic provision of integrated cross-platform software such as combinations of databases, software development environments with operating systems. An example would be Microsoft Azure.

• Applications of Infrastructure-as-a-Service (IaaS): Elastic provision of computation (servers) and storage. An example would be Amazon Web Services’ EC2.

This method of layering and naming has also given rise to the popularity of using “as-a-service” to describe cloud-delivered services, for example, security-as-a-service (SecaaS), which will be covered in Chapter 9.

Another way to look at cloud services would be to look at the scope. If a particular cloud service is run entirely on-premise, and within your own organization’s physical boundaries, it is generally known as the private cloud (note: some vendors may have varying understandings depending on their sales pitch). If it is run entirely outside of your organization’s physical boundaries, it will be generally referred to as a public cloud. If it is a mix of both public and private cloud, it is commonly referred to as a hybrid cloud.

At the time of writing, the hybrid cloud approach is the most common approach by both vendors and consumers mainly due to data sovereignty and data governance considerations. Roles of the cloud, such as the role of a so-called “cloud broker,” are still under much debate and have not witnessed consolidation. Hence, it is not the interest of this book to discuss this, and we take a simple approach—cloud vendors/service providers versus cloud consumers/users.

It is important to note that regardless of public, private, or hybrid boundaries, the service consumer technically provides the data and mostly owns the data. However, that may change when they upload their data into the respective cloud services. For example, in some free social media sites, the copyright of user-uploaded pictures technically belongs to the social media site after the upload. Important issues such as legal implications for cloud service providers and users if the data is breached or users suffer an economic loss resulting from the provider’s negligent act have also remained unanswered (Choo, 2014a, 2014b).

There will always be some percentage of a loss of control over how their data are managed or processed. In other words, we always have to depend on a trusted administrator or provider to handle the processing of our data.

This brings us to the crux of what this book is about—the complications caused by the dependency of a trust relationship between a service provider and a service consumer.

3.1 Case study 1: breach of trust by a public cloud system administrator

In 2010, Google fired its site reliability engineer, David Berksdale, for breaking Google’s internal privacy policies (Chen, 2010). Berksdale was found to have misused his position to break into the Google’s cloud e-mail service (Gmail) and Internet phone service (Google Voice) accounts of several children. Particularly, he spied on four teenagers for months before the company was notified of the abuses. Some of the abuses include the accessing of contact lists and chat transcripts. Notice that Google did not know about these abuses, and reportedly “it was unclear how widespread Barksdale’s abuses were” (Chen, 2010).

In one of the incidents in Spring 2010, Barksdale tapped into the call logs of a 15-year-old boy’s Google Voice after the boy refused to tell him the name of his new girlfriend. After accessing the boy’s account to retrieve her name and phone number, Barksdale taunted the boy and threatened to call her.

These incidents not only highlight the dangers of “trusting” a third party but also reveal the lack of technical solutions, legal guidelines, and business management controls for preventing and identifying the risks. We also cannot be assured that there will not be other “Berksdales” in other cloud providers.

This book attempts to highlight, discuss, and address these types of issues in Chapters 2–4.

3.2 Case study 2: liability of a liquidated cloud business

In 2011, storage cloud company Iron Mountain announced its liquidation, shocking several of its customers. In a statement released by Gartner in 2011³:

Many consumers who entrusted their data into Iron Mountain’s storage servers have not previously planned alternative storage. This case also raised the awareness that even large cloud service providers can fold, and consumers should never take their availability for granted. What if public cloud giants such as Google, Amazon, or Microsoft fold? What will happen to the customers’ massive amounts of data and our cloud-dependent lives?

If a company liquidates, what happens to the data stored in the cloud? Who can be held accountable for the state of affairs? What powers do cloud consumers have? These are the questions we will further explore in this book.

3.3 Gatekeepers—governments versus technology creators

In 2011, at the University of the West of England (UWE) in Bristol, UK, Ko attended an interesting symposium which placed legal professionals and computer scientists in the same room—to discuss about the upcoming technical and legal challenges of cloud computing.

At the symposium, the concept of the two “gatekeepers” of technology was proposed—technology creators and the governments. Due to its high concentration of high-tech startups and companies, many view Silicon Valley as the gatekeeper of sorts for several technological advances.

Why was this raised? This is because when one understands the gatekeepers’ concept, we understand the state of the art of our cloud security ecosystem. At the time of writing, the technology creator gatekeepers are currently almost exhausting their capabilities to push the security agenda. Further, Choo (2014a,b) noted that a legitimate need exists for cooperation between the different gatekeepers, but there are also legitimate concerns about cloud service providers being compelled to scan or hand over user data of interest that reside in the cloud or to report on/monitor particular types of transactional data to government agencies without the user’s knowledge or consent due to territorial jurisdiction by a foreign government. In addition, overseas cloud service providers might not be legally obliged to notify cloud users (i.e., the data owners) about such requests.

It is now time for the legal echelons and governments in the international community to take lead. For example, we are starting to see the gradual release of international standards and criteria for cloud security, and development of certified cloud security professionals (CCSP).

Most recently, we witnessed the launch of a new professional certification—the (ISC)2-CSA CCSP (which Ko is one of the pioneer group of subject matter experts developing the curriculum and exam).

4.1 Cloud security alliance’s top threats to cloud computing research

In 2009 and 2010, the Cloud Security Alliance (CSA) published two relevant publications, namely, (1) Security Guidance for Critical Areas of Focus in Cloud Computing v2.16 (Cloud Security Alliance, 2009) and (2) Top Threats to Cloud Computing (Cloud Security Alliance, 2010). In the Top Threats article, seven threats were listed as the top threats to cloud computing (Table 1).

The CSA list is seminal in cloud security as it brought much-needed awareness to the flip side of cloud computing in 2009. For example, because of the low price and availability of cloud services, it is easy for a malicious attacker to use the cloud for nefarious uses. Some news articles have mentioned about the use of cheap cloud servers to crack Wi-Fi access points’ passwords via sheer brute force.⁴

It is also interesting to note that all threats have elements of technical, legal, and management aspects involved. The focus has always been on the technologies but this view has to broaden to take a holistic ecosystem view for true risk management. It is not surprising and cyber security is no longer the preserve of any single country, entity, (industry) sector, or disciplinary field because of the nature and extent of an increasingly connected and sophisticated technological and user bases (Choo, 2014a,b). There is, therefore, a need to bring together perspectives and approaches from different disciplines and countries and investigate what we can do singularly and collaboratively to secure our cyber space and future.

However, while these pioneering CSA documents raised the awareness of the threats, the documents depended on initial expert opinion but were unable to gather ample empirical support for the justification of the top threats—which is extremely difficult to achieve without participation from all stakeholders. Empirical data enable the research and practitioner industry to focus on addressing the “true” reported top threats. While the Top Threats report highlighted the potential risks cloud users and service providers face, debates about whether opinion-based lists such as the CSA top threats (and the latest version—the so-called Notorious Nine) stand to hold against the test of time.

For example, the CSA top threat “Shared technology issues” highlights the potential for a company A to look into company B’s data while sharing the same cloud technologies via multitenancy software controls. At the time of writing, it is a common view among the cloud security research and practitioner communities that this is a relatively remote risk, and this has been the subject of various research initiatives.

4.2 Statistics of common vulnerabilities faced by cloud service providers

This calls for the need for empirical data to study the “real” situation. Given cloud computing is still in its early stages, and the general reluctance for companies to release public data on cloud security-related outages, it is very difficult to achieve full empirical analysis on the top threats and vulnerabilities of cloud security.

The closest empirical study was perhaps the 2013 study conducted by Ko et al. (2012, 2013) of the Cyber Security Researchers of Waikato (CROW) at the University of Waikato in New Zealand, and Nanyang Technological University and Cloud Security Alliance’s Asia Pacific region in Singapore. This study looked at 11,491 news articles on cloud computing-related outages from 39 news sources (e.g., CNet, TechTarget, CNN, etc.) between January 2008 and February 2012—effectively covering the “first 5 years” of cloud computing’s boom in a best effort fashion. Through a strict definition and qualification process for what constitutes a “cloud outage” incident, 172 unique incidents were identified from the overlapping, duplicated news articles (note: this also shows the state of today’s news dissemination). While it does not necessarily cover the entire cloud security ecosystem, it is the “best one can get” given the nature of security incident disclosures.

Of the 172 reported cloud vulnerability incidents, 129 (75%) declared the cause(s) while 43 (25%) incidents did not. It was observed that the top three cloud providers, Amazon, Google, and Microsoft, account for about 56% of all nontransparent incidents of cloud vulnerability. It was also reported that beginning in 2010, cloud providers became more transparent with their reports of cloud vulnerability incidents, most likely because Amazon became more open about the causes of their incidents. As is to be expected with the growth of cloud vulnerability, over the years, the number of cloud vulnerability incidents has risen (see Figure 1). In fact from 2009 to 2011, the number of cloud vulnerability incidents more than doubled—from 33 to 71, most likely due to the phenomenal growth in cloud services.

The statistics collected from actual news reports not only validated CSA’s top threat categories but also empirically revealed five newly discovered categories of vulnerabilities in cloud security. Five new threat categories (T8—Hardware Failure, T9—Natural Disasters, T10—Closure of Cloud Service, T11—Cloud-Related Malware, and T12—Inadequate Infrastructure Design and Planning) are needed for a more accurate representation of cloud outage threats and vulnerabilities. The new CSA revised threat list encompassing reported outages is listed in Table 2.

Figure 2 shows the frequency of occurrence of the existing seven CSA threats and five new threats proposed by the authors of the vulnerability statistics report. The three most frequent incidents are (Ko et al., 2012, 2013):

– CSA Threat 2 “Insecure Interfaces & APIs” with 51 incidents accounting for 29% of all threats;

– CSA Threat 5 “Data Loss & Leakage” with 43 incidents accounting for 25% of all threats reported;

– CSA Threat 8 “Hardware Failure” with 18 incidents accounts for 10% of all threats reported.

All other threats have 15 or fewer cloud vulnerability incidents each, accounting for 8.5% or less. A Pareto analysis reveals that the first three threats, CSA Threat 2, CSA Threat 5, and New Threat 8, account for 64% of all cloud vulnerability incidents, although collectively they make up only 25% of total threats (see Figure 2).

This study also reported that most vulnerabilities (except two, namely, Insecure Interfaces & APIs and Data Loss or Leakage) are decreasing by the year, showing an improvement and stability of cloud computing services. However, the top three culprits (Insecure Interfaces & APIs, Data Loss or Leakage, Hardware Failure) form about 60% of the incidents! If we can reduce them, the cloud security ecosystem will definitely be very reliable. The study also shows there are still lots of room for accountability to the users. Prominent cloud service providers with large market shares have to take the lead and show increased transparency.

It is our hope that readers and organizations using the cloud or developing cloud services take note of these top risks, so that they can identify and manage them in advance of a catastrophic event. This leads us to Section 5.