The Cloud Security Ecosystem: Technical, Legal, Business and Management Issues

2015

Chapter 1

Cloud security ecosystem

Ryan K.L. Koa; Kim-Kwang Raymond Choob    a University of Waikato, Hamilton, New Zealand

b Information Assurance Research Group, School of Information Technology and Mathematical Sciences, University of South Australia, Adelaide, Australia

Abstract

This chapter introduces the reader to the initial developments of the cloud computing industry, consolidated cloud-related terminologies, and concepts, and explains the main reasons and causes of the cloud security and privacy concerns.

Keywords

Cloud security ecosystem

Cloud security

Cloud data privacy

Cloud computing

Cloud computing (Ko, 2010) may be the most important information technology (IT) innovation of the twenty-first century, and it is now common to see individuals and organizations using online computing services that classify themselves as cloud services. While cloud is becoming mainstream, several aspects of cloud security and privacy concerns are still in development or unaddressed.

1 How it all started—the story of an online bookstore

It is not clear when the term cloud computing was first coined (Choo, 2010). However, cloud computing started to become prevalent in 2008 on the back of the USA presidential election, and some mentioned the success of the campaigns were hinged to the scale and elasticity brought forth by cloud computing.

To most cloud industry practitioners, the concept of cloud computing started from an online book shop—Amazon.com in 2003. That year, the world was still counting its losses from the Dotcom bubble burst, and the world’s largest online bookstore was facing a critical economical decision-making problem—resource utilization versus capital investment.

Werner Vogels, then Amazon’s Chief Technology Officer (CTO), said From experience we knew that the cost of maintaining a reliable, scalable infrastructure in a traditional multi-datacentre model could be as high as 70%, both in time and effort, and requires significant investment of intellectual capital to sustain over a longer period of time.¹

Hence, the company’s goal was to deliver services that could reduce that cost to 30% or less.² In other words, Amazon was trying to grow their infrastructure while finding out a method to offload the operational costs to others. While Amazon’s servers are up 24 hours a day, 7 days a week, there are constantly ups and downs in terms of demand for the utilization of the servers, at different time zones around the world. It would be great if the wastage of utilization can be offloaded to some other customers who may need it. When the folks in Asia are sleeping, wouldn’t it be great that the related underutilized servers serving them can be sold for usage by the businesses in the Americas?

In the meantime, Chris Pinkham and Benjamin Black, another Amazon engineer, wrote a short paper outlining the ideas for Amazon's chief executive officer (CEO) Jeff Bezos, who liked it and followed up by asking for more details on a virtual cloud-provisionable server.

However, Pinkham and his wife had a baby on the way and, after talking with other people at Amazon, left to set up a satellite development office in South Africa—Amazon's first in the region—where he and some other engineers, including Christopher Brown and Wiljem Van Biljon, worked on designing the Amazon EC2 service.

In 2006, the cloud services for computing (EC2), storage (S3), and outsourcing of tasks only achievable by humans (Mechanical Turk) were launched. The rest, as they say, is history.

Since that movement, several IT companies have embraced cloud computing. Google positioned themselves as a public cloud service provider. Microsoft quickly joined the fray by offering its Azure services. Startups such as Foursquare, DropBox, Quora, and many young IT companies were started quickly over the Amazon cloud services—without the need to invest in hardware up front.

Even the large IT companies (such as Oracle and SAP) that initially dismissed cloud computing as a buzzword has come to accept its business model and have entered the market to offer what is known as a hybrid cloud. This brings us to the next and very necessary section (Section 2).

2 Consolidation of terminologies and perspectives

As with many IT paradigms, cloud computing has its fair share of overlapping terminologies. If you are coming into this field as a professional or a student in the recent year(s), you would be heartened to know that the concept of cloud computing has consolidated to the following perspectives.

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 The achilles’ heel—depending on a trust relationship

The root of the perennial cloud security and privacy problem stems from the basis of a trust relationship.

By signing up for the use of a cloud service—whether it is private, public, or hybrid—we are explicitly placing our trust into the people running the services to observe the highest ethical principles. This may not always be the case.

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³:

On 8 April 2011, Iron Mountain confirmed that it is sunsetting its public cloud storage business. The company said that the official end date for the service would be no sooner than the first half of 2013, but said it stopped accepting any new customers as of 1 April 2011. Iron Mountain says it will continue to offer services to its current cloud storage customers, help them migrate to another provider or return the data. Virtual File Store customers that stay with Iron Mountain will be transferred to a higher-value offering, File System Archiving (FSA) in 2012. The new offering will be a hybrid that leverages policy-based archiving on site and in the cloud with indexing and classification capabilities. Archive Service Platform customers have no migration path and are being terminated or moved to an alternative service