On the Security Assessment of the Cloud

On the Security Assessment of the Cloud

A plethora of highly effective Threat Analysis (TA) techniques exist that focus on analyzing threats to specifically targeted assets (e.g., components, services), typically considering static interconnections among them. On the other hand, the Cloud is a dynamic environment where resources can instantiate or migrate to provide rapid scalability to the users. In addition, there is an increasing number of complex attacks that target multiple assets in the Cloud systems. Thus, security assessment of the Cloud requires the following aspects:

  • Analysis of multi-asset attacks and the support for dynamic interconnections in the Cloud, enabling the exploration of a threat’s behavior and propagation across the Cloud.
  • Evaluating the impact of multiple threats across various operational assets, contributing to tracing actual Cloud attacks, and speculatively postulating alternate potential attack paths.

System design

Several delivery models exist for the Cloud, such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), primarily emphasizing the functionality and performance of these models. However, our primary focus is on the threat and its propagation across the Cloud. Therefore, we design a generalized 3-layered (Control, Infrastructure, and Storage) architecture exhibiting the Cloud’s functionality. Furthermore, threat propagation analysis has to be agnostic to the technologies implementing the functionality. Figure 1 presents the Cloud model.

Figure 1: Multi-layer architecture of the Cloud

Each layer is responsible for specific operational tasks. We detail each layer’s functionality in the following sections.

Control layer: The primary role of this layer is to authenticate the user. Once authenticated, a user can restart Virtual Machines (VMs) or instantiate new VMs.

Infrastructure layer: The role of this layer is to bind physical hardware to the virtualized resources and maintain isolation among the VMs of different users.

Storage layer: The storage for the VMs is provided by this layer.

Translating the Cloud model to an information flow model

In order to ascertain threat propagation, the interconnection among the services/layers has to be detailed. Thus, we translate the Cloud model into an information flow model to enable tracking of a threat’s progression in the system. An example of this translation for the login system is shown in Figure 2. The figure has three places (Log_Reqs, Usr_Accns, and On_Usrs) and two transitions (Auth_F, Auth_S). The preconditions of these transitions are shown on the arcs such that: (i) the set U represents the username and password provided by a user, (ii) the set 𝐶 are the credentials known to the server, and iii) the set O represents the users that are already online. For instance, the transition Auth_S takes input from all three sets, and if the user is not online and the credentials match with the stored credentials, the user is authenticated. A violation in any of these requirements will fire Auth_F instead, and the user would have to reenter valid credentials.

Figure 2: Technology-agnostic Login System in the Cloud.

Similarly, we define the remaining services in the Cloud and the threat’s behavior in a technology-agnostic manner. The result is the complete translation of the Cloud model to an information flow model highlighting the service’s interconnections.

Threat analysis using our proposed approach

The benefit of creating an information flow model is that it allows us to support expressing the functional behavior of the Cloud as well as the threats in a technology-agnostic style. Consequently, identify violations from the sequence of events by determining the modifications in the operations of the Cloud caused by spurious input to the system. An example of spurious inputs in the form of different vulnerabilities is given to the Cloud model, and the result is shown in Figure 3. There are several paths that lead to the resource consumption state of the system from the given inputs.

Figure 3: Attack Paths generate using our approach
  • Path 1. Successful exploitation of vulnerabilities in path 1 of Figure 3 leads to attaining additional resources in the Cloud from a disabled user. It is accomplished by exploiting vulnerability CVE-2013-4222/CVE-2012-4457 to request a new authorization token of the disabled user and utilizing this token in accessing the victim’s resources. A precondition of the attack requires authentication of the user, which could be achieved by exploiting either vulnerability CVE-2013-2006 or CVE-2015-3646 in the control layer.
  • Path 2. Exploiting CVE-2014-5251 at the control layer allows attackers to bypass access restrictions and potentially discover restricted projects. However, in combination with CVE-2018-14432, an attacker can escalate the impact to retain  access to these restricted projects with an expired authorization token. Alternatively, an attacker in combination with vulnerability CVE-2016- 0757 at the infrastructure layer might be able to change the VM’s configuration. This path shows that combining vulnerabilities from different layers can increase the overall impact. Therefore, the potential of a threat’s progression should be considered in the threat analysis process.

Thus, our threat analysis methodology fills the gap in state of the art by incorporating the dynamic characteristics of the Cloud into a threat analysis process. This has resulted in the capability to perform speculative analysis on dynamic Cloud behavior without limiting the threat analysis to a specific technology or a service. Threats from the national vulnerability database have been modeled to demonstrate how these threats can be considered in the speculative analysis as well as identifying attack paths in different real-world attacks on Cloud systems.

(By Manzoor Salman, Lancaster University (ULANC), United Kingdom)