RISK AND CLOUD

The previous sections, although not directly related to cloud computing, were needed to frame the context of the discussion of risk in using the cloud: the multi- faceted nature of uncertainty and language depend on specialization. With respect to cloud computing, prob- ably the main question related to risk is: which risk or risk aspects are peculiar to cloud computing and, conse- quently, require new analyses and solutions with respect to traditional ones developed for networked, distrib- uted information systems? In short: is there something new that cloud computing brings to risk analysis and management?

The answer that the literature is telling us is not uni- versal; it is not clearly recognized whether cloud com- puting is introducing new IT risks and what they are. A lot has been written in the last decade on cloud com- puting and security, but still the definition of cloud- specific risks is an open issue. We will summarize the state-of-the art of current research and debate.

8.4.1 Security Risks Not Specific to Cloud Computing

Yanpei et al. [12] in 2010, analyzing security problems

affecting cloud computing environments, titled their

report What’s new about cloud computing security?, sig- naling that the answer was not trivial, and that probably there was a certain degree of overhyping in frequent announcements of new security threats brought by cloud computing. Rather, as declared by the authors: “We argue that few cloud computing security issues are fundamentally new or intractable; often what appears ‘new’ is so only relative to ‘traditional’ computing of the past several years.”

Therefore, assessing security and also risk issues of cloud computing, the first effort should be devoted to exclude problems that are not specific to cloud comput- ing and for which established solutions or countermea- sures are already known and available. “Do not reinvent the wheel” is always the rule of thumb in these cases.

Let us consider the NIST definition of cloud com-

puting [13], one of the most cited: “Cloud computing

is a model for enabling ubiquitous, convenient, on- demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provi- sioned and released with minimal management effort or service provider interaction.” There are five essential characteristics: • On-demand provision • Network service • Resource pooling • Rapid elasticity • Measured service

Such model, with respect to customers, is almost always implemented through a web-based remote con- figuration interface. The setup could certainly suffer from traditional problems related to web applications, remote communications, and misconfigurations (by mistake or purposeful). Incidents may happen (and did actually happen), but from the point of view of the analysis, the causes should not be related to cloud computing. For instance, a loss of confidentiality on the communication channel may happen from a vul- nerability in an encryption library, but that is neither a “cloud computing vulnerability” nor a “cloud comput- ing risk.” It is a vulnerability/risk of all remote commu- nication using such library. The same is true in case of an attacker guessing the credentials for remote access

to a configuration pane, because it is a problem gener- ally affecting all configurable provision of networked services. Many other similar cases can be identified, but the important message here is: do not label old problems as new, because already established solutions are very likely to be more accurate, efficient, and cost-effective than developing new ones from scratch. Considering the cloud provider, even in that case many problems that may arise are the same of all data-hosting setups. Data inconsistency, backups, network failures, blackouts, and errors by system administrators, as well as typical security threats of all networked organizations, are not cloud-specific in general. The necessary network pro- tection, business continuity and disaster recovery, user authorization, and authentication are the same for all data-hosting providers.

Unfortunately many analyses, both academic and industrial, do not make such an effort of clarifica- tion and consider too many security risks as cloud-

specific [14–17]. For instance, in Understanding Cloud

Computing Vulnerabilities [18] the authors adopt the same NIST definition of our chapter, but the logic of their analysis differs substantially from ours. For instance, they affirm that “if a vulnerability is prevalent in state-of-the-art cloud offerings, it must be regarded as cloud-specific. Examples of such vulnerabilities include injection vulnerabilities and weak authentica- tion schemes.”

However, injection vulnerabilities and weak authen- tication schemes are among the most common web application vulnerabilities (actually they were the two

most common in OWASP’s top 10 of 2013 [19]). Along

with that line of reasoning, the logical consequence would be to incorporate under the label of cloud- specific an inordinate amount of vulnerabilities actu- ally not specific to cloud, but specific to the underlying technologies. That way, the risk is to confound analysts and practitioners by overlapping web applications to cloud computing, the former being a set of technolo- gies, the latter a model for service provision that is implemented by means of traditional and novel tech- nologies (this way, inheriting both their strengths and weaknesses) and providing improved benefits and pos- sibly introducing new vulnerabilities. Therefore, as we do not identify cloud computing benefits with those of generic web applications but instead we stress specific novelties, in the same vein we should label as cloud- specific only peculiar vulnerabilities.

8.4.2 Cloud-Specific Risks

The search for convincing analyses of cloud-specific risks and security vulnerabilities has occupied IT ana- lysts since the beginning of the cloud computing era in the past decade, and still continues today. Cloud bene- fits for enterprises have been marketed vigorously, while free services, initially not recognized as cloud-based (e.g., free email services), have gained enormous success among the users.

Let us start with one of the most cited and influ- ential analyses so far about cloud computing risk: the 2009 report by ENISA, the European Union agency for network and information security. The report is not recent—6 years is an enormous time interval for innova- tive IT services—and read today it clearly shows the lack of practical experience at the time of writing. Instead, the report is based on hypotheses drawn by a pool of experts and the editors. They evidently worked by anal- ogy taking inspiration from comparable scenarios, like data-hosting, web services, and networked systems. However, the authors also made a remarkable effort to point to cloud-specific risks. In particular, they recog- nized management and contractual issues as strikingly important for cloud computing and put considerable emphasis on them. In short, the most important risks they identified were:

• Loss of governance • Lock-in

• Isolation failure • Compliance risk

• Management interface compromise • Data protection

• Insecure or incomplete data deletion • Malicious insider

This list mixes user-side and provider-side risks, but it is particularly interesting because three out of the eight risks are not technical and mostly based on con- tractual agreements and governance of information sys- tems (i.e., loss of governance, lock-in, compliance), one is related to the high redundancy and dynamical reloca- tion of data typical of cloud computing (i.e., insecure or incomplete data deletion), the others are mostly generic

threats not really specific to cloud computing. It is also interesting to look at the list of less important risks men- tioned by ENISA. Many of them are not cloud-specific risks, like those from data in transit on the net or dis- tributed denial of service (DDoS), but some are cleverly cloud-specific: Loss of business reputation due to cote- nant activities sounds awkward somehow (i.e., why only reputation risks from cotenants activity?), but has the important merit to point to multitenancy as one impor- tant source of cloud risks; Conflicts between customer hardening procedures and cloud environment is again a bit too narrowly specified and hypothetical, but implic- itly it highlights one of the most, if not the most, critical cloud-specific risk: the possible mismatch between cus- tomer’s security policies and those of the cloud provider and the difficulty (or impossibility) to perform an audit. This is a particularly insidious risk because technical, governance, and contractual aspects are entangled and it proves extremely difficult to analyze, measure, and in some way mitigate the risks coming from such a multi- faceted nature.

NIST’s counterpart of the ENISA report was Special Publication 800-144 Guidelines on Security and Practice in Public Cloud Computing, published in 2011. While extremely comprehensive and in many parts similar to the analysis done by ENISA, NIST was not as pre- cise and categorical as ENISA to identify cloud-specific risks. The narrative is more elaborated and many tradi- tional security issues are discussed, sometimes overlap- ping with other NIST publications. However, following the introduction, it highlights a crucial family of risks that ENISA only implicitly grasped: risks hidden in the specification of an SLA. Here is what NIST authors said: “Public cloud providers’ default offerings generally do not reflect a specific organization’s security and privacy needs,” which is similar to ENISA’s Conflicts between Customer Hardening Procedures and Cloud Environment. But then, they continue: “Non-negotiable service agree- ments in which the terms of service are prescribed com- pletely by the cloud provider are generally the norm in public cloud computing. Negotiated service agreements are also possible. […] Critical data and applications may require an agency to undertake a negotiated service agreement in order to use a public cloud.” This is a cru- cial point that nowadays it is still the subject of many researches, reports, and discussions about cloud risks, and still with no clear and practical solutions. On the one side, it has been recognized that standardized SLAs

offered by cloud providers do not satisfy the need for risk management of many customers and, in addition,

do not include security level measurements [20,21].

Thus, security-oriented and negotiated SLAs would be required. On the other hand, cloud users, on average, do not have the negotiating power for imposing contrac- tual conditions to economic behemoths like cloud pro- viders, which base their business model on strict service standardization to reduce management costs, increased automatization, and economies of scale. In this situation lies the unresolved problem: SLA customization on a per customer basis is both needed and impractical for man- aging cloud risks. As we will see, many research efforts are now dedicated to this issue.

8.4.2.1 Fate Sharing

Considering again What’s New about Cloud Computing Security [12], it is the multitenancy characteristic and the business and technical difficulty of auditing that are identified as the two most relevant cloud-specific sources of risk. Both have profound implications in a cloud computing ecosystem. The multitenancy is responsible for a full spectrum of new threats, i.e., new meaning new for the technicalities or new for impact magnitude and/or the likelihood of the event.

In Ristenpart et al.’s article [22], the shared resources

environment is exploited to permit side and covert channels between colocated virtual machines; whereas

in What’s New about Cloud Computing Security [12] the

multitenancy could be responsible for fate sharing. Fate sharing of cloud cotenants is exemplified in two epi- sodes: The first is the reputation damage due to loss of availability (e.g., of a service provider) caused by a DoS

attack targeting a cotenant [23], and the second is the

seizure of equipment requested by a law enforcement

agency following a criminal investigation [24].

8.4.2.2 Mutual Auditability

The second aspect analyzed in What’s New about Cloud Computing Security [12] is mutual auditability of cloud users and providers. Mutual auditability would be the logical consequence of more complex relationships between cloud actors with respect to a typical service user/provider scenario. We have already pointed to some of the main reasons of such a high complexity: the entangling of technical, governance, and contrac- tual issues binding cloud users and providers. Mutual auditability would be needed for measuring service and

security levels, for better resolving incidents and recov- ering procedures, and is a requirement for the definition of extended, negotiated, and customized SLAs. As said though, whereas in theory the benefit of mutual audit- ability has been recognized long since, in practice it never happens that a cloud customer could audit a cloud provider, except in exceptional cases.

Theoharidou et  al. in a recent study [25] point to

multitenancy too, as the fundamental source of cloud- specific risks. In their research, privacy risks deriving from multitenancy have been studied. Compliance and accountability are found to be particularly challenging, again, due to the high complexity governing the relation between cloud users and the provider.

8.4.2.3 Insider Threats

A different result was reached by Ryan in his analy-

sis  [26]: “Therefore, the genuinely unique challenge

posed by cloud computing security boils down to just one thing: The data in the cloud can be accessed by the cloud provider.” In his view, hence, it is not mul- titenancy that is the real differentiating factor with respect to known security risks, but instead the transfer of control and management over data and assets from the owner to a provider. Under this perspective, cloud providers cannot be compared to simple data-hosting services, because the key feature is not data storage (for which traditional encryption would be the solu- tion for privacy); instead, cloud providers are required to execute “non-trivial computations,” which changes according to the type of cloud service (i.e., service/ platform/ infrastructure as a service). Advanced cryp- tographic techniques like secure multiparties computa-

tion [27–29] or fully homomorphic encryption [30] have

been studied for cloud computing, but while promising, these are methods that inevitably increase the complex- ity of the solution at a point still difficult to manage in production for large-scale cloud systems. Then, the risk envisaged by Ryan of how to guarantee confidential- ity from a cloud provider must still rely on contractual obligations forbidding a provider from disclosing cus- tomer data, but there is no clear technical solution that is going to be applied in large commercial environments. A recent research about confidentiality risk in cloud processes is a first attempt to provide a detailed opera- tional solution, although still based on strict modeling

assumptions and gambling case studies [31].

Claycomb and Nicoll of CERT noted instead how the typical threats posed by insiders have cloud-specific

connotations worth deep investigation [32]. The obvious

threat posed by insiders is that of a rogue administra- tor of the cloud provider, who could evidently provoke every sort of severe damage. However, the case is not fundamentally different from every data-hosting com- pany and, according to CERT authors, we have little evidence about that from data on incidents. The authors consider two additional cases instead, more tailored for a cloud scenario: an insider exploiting cloud-specific vulnerabilities and an insider using a cloud system to sabotage some provider’s local resources. In the first case, the privileged position of the insider could permit him/her to identify and exploit vulnerabilities in the cloud infrastructure to gain access to sensitive informa- tion to sell or use for personal advantage. In the second case, instead, an insider could use his/her position to use the cloud resources for illegal purposes (e.g., launching a DDoS toward an external target) or to exfiltrate sensi-

tive information [33].