I.Introduction

As cloud services emerge, interest in security for cloud environments is increasing rapidly. According to Symantec’s “2019Internet Security Threat Report,” more than 70 million data leaks have occurred in 2018. This implies that security vulnerabilities in cloud environments are continuing to increase [1].

Meanwhile, Gartner reported positive expectations for the growth of the cloud service market. Table 1. shows the scale of the market growth expected by Gartner. Gartner predicted that the cloud market size will be 331.2 billion dollars in 2022, i.e., 1.81 times that of the cloud market in 2018. Additionally, the size of the cloud security market is expected to be 17.9 billion dollars, i.e., 1.65 times its size in 2018 [2].

Table 1. Gartner Cloud Service Forecast

Hence, cloud services are expected to expand steadily despite the high possibility of various security vulnerabilities. As cloud services expand steadily, the forms and compositions of cloud environments are becoming more diverse. As these forms become more diverse, components with various environments and features are appearing. Hence, cloud networks are capable of providing various services using various components; however, owing to the tradeoff between providing services and security, a variety of security threats are expected to occur in cloud environments. As components become more diverse, vulnerabilities in cloud networks are changing to more complex and diverse forms owing to the variety of component vulnerabilities. Therefore, it is necessary to be able to distinguish and detect the vulnerabilities of various components in cloud networks.

A cloud network vulnerability detection method using  STRIDE and HARM is proposed herein for the security of cloud networks that is expanding owing to various components. The vulnerability detection scheme presented herein was used on CVE vulnerability, and the vulnerabilities of each cloud network component were distinguished based on the STRIDE threat classification scheme to distinguish and classify vulnerabilities. In addition, HARM was used to visualize the exploits, hosts, and vulnerabilities [3][4].

In the vulnerability detection scheme presented herein, it is possible to use CVE to perform a detailed analysis of which actual environments can experience certain vulnerabilities. Furthermore, it is possible to distinguish vulnerabilities in a cloud environment where a variety of components exist through vulnerability classification that uses STRIDE. Using HARM, attack graphs for each component and vulnerability can be computed.

Section 2 discusses the definitions and usage methods of CVE, STRIDE, and HARM. Section 3 describes the operating process of the proposed cloud network vulnerability detection scheme based on STRIDE and HARM. Section 4 provides a scenario-based analysis of the proposed scheme’s features and performance. Section 5 presents the conclusions.

II. Related Work

2.1 CVE Vulnerability

CVE represents “Common Vulnerabilities and Exposures”[5] and it is a service providing definitions for publicly released cybersecurity vulnerabilities. The goal of CVE is to allow data to be shared easily using these definitions. CVE items include identification numbers, descriptions, and references [6].

The CVE ID format consists of ”CVE prefix + year + sequence number digits,” and IDs are assigned in a format such as “CVE-2014-99999.” These CVE IDs are used to perform CVE searches. Furthermore, CVE IDs are primarily used for threat identification that is performed in various security products and services [6]. Therefore, a vulnerability detection method is proposed herein that is used on CVE vulnerabilities that can occur in a cloud network where a variety of components and services exist.

The method is targeted at components that can exist in a cloud network virtual environment (Linux Kernel, Wordpress, Ubuntu, etc.). In this study, collected CVE vulnerabilities occur easily because the actual exploit codes exist and can be used. The collected CVE vulnerability examples are shown in Table 2.

The features of the vulnerabilities shown in Table 2. are as follows.

Table 2. CVE List

● CVE-2019-7304
This is a vulnerability that can occur in standard snapd up to version 2.37.1. In this vulnerability, an attacker can execute a given command as a root owing to the improper implementation of the socket owner validation [7]. Part of the exploit code for executing the vulnerability is shown below [8].

Fig. 1. CVE-2019-7304 Exploit code

● CVE-2017-10661
This is a vulnerability in which operations can be performed on the file descriptor to obtain privileges using the might_cancel queue that is a race condition of fs /timerfd.c in the Linux kernel up to Version 4.10.15 [7]. Part of the exploit code for executing the vulnerability is shown below [9].

Fig. 2. CVE-2017-10661 Exploit code

● CVE-2019-6111
This is a vulnerability that can occur in Ubuntu 14.04/16.04/18.04. An attacker can use an scp to verify the vulnerability to overwrite a given file in the scp client’s target directory [7]. Part of the exploit code for executing the vulnerability is shown below [10].

Fig. 3. CVE-2019-6111 Exploit code

● CVE-2019-5418
This is a vulnerability that can occur in Debian Linux 8.0. An accept header created by an attack can be used to leak the content of a given file [7]. Part of the exploit code for executing the vulnerability is shown below [11].

Fig. 4. CVE-2019-5418 Exploit code

● CVE-2018-6389
This is a vulnerability that can occur in Wordpress 4.9.2. A list of js files registered by an attacker can be used to create the DoS (resource consumption) [7]. Part of the exploit code for executing the vulnerability is shown below [12].

Fig. 5. CVE-2018-6389 Exploit code

● CVE-2017-16995
This is a vulnerability that can occur in the Linux kernel Version 4.14.8. An attacker can use the check_alu_op function of kernel/bpf/verifier.c to obtain root permission [7]. Part of the exploit code for executing the vulnerability is shown below[13].

Fig. 6. CVE-2017-16995 Exploit code

2.2 STRIDE

STRIDE is a classification system developed by Microsoft for threat classification [14].

It consists of S(Spoofing), T(Tampering), R(Repudiation), I(Information disclosure), D(Denial of service), and E(Elevation of privilege). Listed below are the descriptions of each element.

● S(Spoofing)
This is a well-known threat to wired/wireless networks in which the attacker can access a network and its resources[15]. In addition, the attacker can use the masquerading IP address or MAC address of each host on the network, and these attacks are known as IP spoofing and MAC spoofing, respectively [16].

● T(Tampering)
The attacker extracts a user’s resources and modifies the resources [17]. In various environments, many attacks can be occurred such as tampering with firmware[18].

● R(Repudiation)
The attacker claims to not have performed or not responsible for an action [19]

● I(Information Disclosure)
The attacker accesses resources for which they do not have permission and leaks the resources’ information [19].

● D(DoS)
The attacker consumes a large amount of the victim’s processing power, memory, disk space, or network bandwidth such that legitimate users cannot use a service [20]. Examples of DoS attacks afre: UDP attack, HTTP attack, SYN flood, etc[21].

● E(Elevation of Privilege)
The attackers enable tasks that are otherwise impossible by increasing their permissions[19]. Highest privilege configuration results in a insecure network[22].

STRIDE is primarily used to respond to vulnerabilities through the vulnerability analyses of each component. Karahasanovic, Kleberger et al. used STRIDE and TARA to analyze vulnerabilities in automobiles in “Adapting Threat Modeling Methods for the Automotive Industry.”[23]. According to their study, network vulnerabilities can be detected using STRIDE in a variety of network configurations. Therefore, to detect vulnerabilities in cloud network environments where various components exist, STRIDE is used in this study to classify known CVE vulnerabilities and subsequently use them to identify vulnerabilities for each component.

2.3 HARM

HARM is a method that examines the overall network graph, divides it into a hierarchy, and examines the vulnerabilities of each network node to compute a new network graph[4].

A graph exhibiting vulnerabilities that can occur in an overall network is assumed to resemble Fig. 7. In Fig. 7, the attacker, User 1, and User 2 are network components, and the lists of vulnerabilities show the vulnerabilities for each component. The arrows show the path and direction of the attack. The graph of attacks that can occur in an overall network configuration is assumed to resemble Fig. 8.[4]. When computing an attack graph of an overall network configuration such as Fig. 8, some difficulties occur in detecting threats that can appear across multiple network components owing to the one-dimensional attack graph.

However, HARM computes attack graphs that are based on components and vulnerabilities, and it can detect threats that can appear across multiple network components. Shown below are the procedures for using HARM on Fig. 7. to compute an attack graph for each component[4].

Fig. 7. Network Graph based vulnerabilities

● Step 1 : Compute an attack graph of the network graph
Compute an attack graph that uses all the components and the vulnerabilities for each component in a network graph. Herein, Fig. 8. is used.

  

Fig. 8. Attack Graph

In Fig. 8, the goal of the attacker is to obtain the root permissions of User 1 and User 2. The attacker can exploit one or several vulnerabilities to obtain the desired permissions[4]. The white rectangles represent the vulnerabilities, and the gray rectangles represent the hosts. The black rectangles represent the targets, and the arrows represent the paths.

An attack graph can be computed using these components.

● Step 2 : Analyze the attack graph
Based on the components and vulnerabilities, possible attack paths are analyzed in the attack graph computed in Step 1.

● Step 3 : Compute an attack graph for each component
Shown below is the attack graph for each component computed from the analysis results in Step 2.

By computing an attack graph such as that in Fig. 9, the vulnerabilities of each component and the paths between components can be created to easily understand the attack paths. Through the example above, it is possible to understand the attack paths of each network component for the Attacker, User 1, and User 2. In addition, four attack paths are possible: A, B, C, and D.

 

Fig. 9. Compute Attack Graph using HARM

Listed below are the specific descriptions of each attack path. The purpose of each attack path is to obtain a user’s root permission.

● Path A(User 1)
Through Path A, the Attacker can use the vulnerabilities of User 1’s ftp_rhosts, rsh, sshd_BoF, and local_BoF to obtain User 1’s root permission.

● Path B(User 1, User 2)
Through Path B, the Attacker can access User 2 through User 1 and use the vulnerabilities of User 2’s ftp_rhosts, rsh, and local_BoF to obtain User 2’s root permission.

● Path C(User 2)
Through Path C, the Attacker can use the vulnerabilities of User 2’s ftp_rhosts, rsh, and local_BoF to obtain User 2’s root permission.

● Path D(User 2, User 1)
Through Path D, the Attack can access User 1 through User 2 and use the vulnerabilities of User 1’s ftp_rhosts, rsh, sshd_BoF, and local_BoF to obtain User 1’s root permission.

In this study, HARM’s attack path and vulnerability analysis are used for each component to analyze the vulnerabilities of each component and create attack paths for each vulnerability to detect vulnerabilities on a cloud network.

III. STRIDE and HARM based Cloud Network Vulnerability Detection

3.1 Information Used by Vulnerability Detection Scheme

Table 3. Section Information

Table 3. shows the information used in the vulnerability detection scheme proposed herein.

The sections in Table 3. are the execution stages of the proposed vulnerability detection scheme. The subsections provide the information used in each stage, and the descriptions define this information.

The cloud network’s configuration is analyzed in the Cloud Network Analysis section’s Compute Graph subsection, and the properties (OS, Kernel) of each network component are analyzed in the Component Analysis subsection.

The collected CVE vulnerabilities are classified in the Presetting section’s STRIDE subsection, and the classified vulnerabilities’ properties (protocol, environment) are analyzed in the Environment subsection.

Through the abovementioned tasks, the Test section performs simulation tests  on the components of the collected CVE vulnerabilities and computes the attack graphs of each vulnerability using HARM. Hence, the computed attack graphs are used in this study for each vulnerability to understand the attack paths of each vulnerability and detect vulnerabilities in a cloud network.

3.2 Vulnerability Detection Scheme Operating Process

Fig. 10. shows the operating process of the cloud network vulnerability detection scheme proposed herein that consists of three phases. The specific phases are cloud network configuration analysis, preliminary setup, and simulation testing/CVE verification, and they are performed in that sequence. The specific operating processes for each phase are as follows.

 

Fig. 10. Cloud Network Vulnerability Detection

3.2.1 Phase 1 : Cloud Network Configuration Analysis

● Step 1 : Compute an overall cloud network graph
This step computes the overall network graph for providing the cloud service and analyzes the cloud components. Analyzing the cloud components allows for attack graphs to be computed later.

● Step 2 : Analyze the properties of each component (communication protocol, environment)
This step analyzes each component’s properties such as its communication protocol and environment. By analyzing the properties of each component, the scheme can identify the possible vulnerabilities of each component later.

3.2.2 Phase 2 : Preliminary Setup

● Step 3 : Collect known vulnerabilities (CVE)
This step collects known vulnerabilities (CVE). Vulnerabilities that can occur on a cloud network are collected, and the collected vulnerabilities become the targets of detection.

● Step 4 : Classify the collected vulnerabilities based on STRIDE
This step classifies the vulnerabilities collected in Step 3 based on STRIDE. By using STRIDE to perform classification, vulnerabilities can be identified/classified on a cloud network where a variety of components exist.
Table 4. shows the results of performing the classification task using the vulnerabilities in Table 2. Hence, the results of performing classification on the collected vulnerabilities with STRIDE can be known.

Table 4. STRIDE Classification

● Step 5 : Analyze the protocols used in each vulnerability
This step analyzes the target protocols where vulnerabilities can occur. Because various components exist on the cloud network, the protocols where vulnerabilities occur can be analyzed to understand the possibility of a vulnerability occurring in a certain component.

● Step 6 : Analyze the target environment of each vulnerability (Kernel, Windows, Linux, Wordpress, etc.)
This step analyzes the environments where vulnerabilities can occur. Because various components exist on a cloud network, the target environments of each vulnerability such as Windows, Linux, the kernel, etc., can be analyzed to understand the possibility of a vulnerability occurring in a certain component’s environment.

3.2.3 Phase 3 : Simulation Testing/CVE Verification

● Step 7 : Simulation Testing
This step uses the collected CVE vulnerabilities to test the vulnerabilities of each component. The actual possibility of a vulnerability occurring can be understood through simulation testing.

● Step 8 : Compute an attack graph for each vulnerability
This step analyzes the results of the simulation tests performed in Step 7. and the vulnerabilities that can occur in each component and uses HARM to compute attack graphs for each vulnerability. Through the computed attack graphs, it is possible to understand the vulnerabilities of the various components in the cloud network as well as the possible attack paths.

IV. Vulnerability Detection Scheme’s Properties and Scenario Analysis

4.1 Analysis of the Vulnerability Detection Scheme’s Properties

Of the previously mentioned phases (cloud network configuration analysis, preliminary setup, and simulation testing/CVE verification) the preliminary setup and simulation testing/CVE verification phases must be performed repeatedly through a feedback process.

In Step 3. of the preliminary setup phase, collection must be performed each time a new vulnerability is created because CVE vulnerabilities are continuously emerging.

In Step 7. of the simulation testing/CVE verification phase, simulation testing must be performed when a new vulnerability emerges to understand the vulnerability in regards to each network component and an attack graph must be computed using HARM.

Plans for responding to the cloud network vulnerabilities are established based on the attack graphs computed by the proposed vulnerability detection scheme.

The proposed cloud network vulnerability detection scheme has difference from HARM as follows.

● Identify specific target environments and vulnerabilities
Unlike existing HARM. it is possible to identify specific target environments and vulnerabilities using STRIDE.

● Integrated recognition of components and vulnerabilities
By using the proposed scheme, it is possible to provide integrated recognition through vulnerability and attack path in the whole network as well as vulnerability and attack path analysis for each component.

The proposed cloud network vulnerability detection scheme provides the following advantages.

● Preventing the spread of secondary damage
Even when a primary intrusion occurs, the proposed intrusion detection scheme can prevent secondary damage by understanding the components where vulnerabilities can occur and computing attack graphs.

● Detecting and visualizing vulnerabilities for a variety of components
A variety of environments and protocols can exist in a cloud environment. It is possible to detect vulnerabilities in a cloud environment where a variety of environments and protocols exist by analyzing the vulnerabilities that can occur in each component’s environment and protocol. The attack path, type, target, and scope of damage can be understood using attack graphs for visualization.

4.2 Vulnerability detection scenario

Based on the created cloud network configuration, the vulnerability detection scheme’s scenario execution process that was presented in Section 3.2 is as follows.

4.2.1 Phase 1 : Cloud Network Configuration Analysis

● Step 1 : Compute an overall cloud network graph
Fig. 11. shows the graph computed for the scenario. The computed network graph consists of a Web Server, VM, and Admin Server, and the protocols and environments of each were set up.

 

Fig. 11. Scenario Example

● Step 2 : Analyze the properties of each component (communication protocol, environment)
Fig. 11. shows the results of analyzing the properties of each component that executes the scenario.

4.2.2 Phase 2 :  Preliminary Setup

● Step 3 : Collect known vulnerabilities (CVE)
To execute the scenario, Table 2. was used for the vulnerabilities collected in this step.

● Step 4 : Classify the collected vulnerabilities based on STRIDE
Table 4. was used as the results of using STRIDE to classify the collected vulnerabilities.

● Step 5 : Analyze the protocol used in each vulnerability

● Step 6 : Analyze the target environment of each vulnerability (kernel, Windows, Linux, Wordpress, etc.)
Table 5. shows the results of analyzing the vulnerabilities in the results of Steps 3 and 4.
Table 5. can be used to understand the properties of each vulnerability (environment, protocol) and they can subsequently be used to understand the vulnerabilities that can occur in each component.

 Table 5. (Step 3,4.)Vulnerabilities Analysis   - : if there are no condition

4.2.3 Phase 3 : Simulation Testing/CVE Verification

● Step 7 : Simulation Testing
Use the selected CVE vulnerabilities to test the vulnerabilities of each component.

● Step 8 : Compute an attack graph for each vulnerability
Analyze the results of the simulation tests performed in Step 7. and the vulnerabilities that can occur in each component, and compute an attack graph for each component. Fig. 12. shows the attack graph computed from Tampering (CVE-2017-10661), which is a result of computing attack graphs computed for each vulnerability.

 

Fig. 12. T(CVE-2017-10661) Attack Graph

4.2.4 Analyze vulnerability detection scenarios

Even though a primary intrusion occurred in the VM and Admin Server, the attack graph of this scenario’s T(CVE-2017-10661) vulnerability allowed for the possibility of secondary spreading and detection of the T(CVE-2017-10661) vulnerability to be recognized in the VM and Admin Server that use a certain environment.

V. Conclusions

STRIDE and HARM based cloud network vulnerability detection was proposed herein to detect vulnerabilities in cloud networks. The proposed vulnerability detection scheme performed vulnerability (CVE) classification using STRIDE and analyzed the properties of vulnerabilities such as protocol and environment to detect the vulnerabilities in various components existing in a cloud network. To prevent the spread of secondary damage from the vulnerabilities used by an attacker, HARM was used to compute attack graphs for each vulnerability. The attack graphs for each vulnerability obtained by performing simulation tests on the collected CVE vulnerabilities were used to simulate countermeasures.

A scenario was presented herein, and the proposed vulnerability detection scheme was executed on the scenario to obtain attack graphs.

The proposed vulnerability detection scheme could perform detection for known vulnerabilities. However, challenges occurred in performing detection for unknown vulnerabilities. Therefore, it will be necessary to detect unknown vulnerabilities in future studies.

* This research was sponsored by the Department of the Nave, Office of Naval Research(ONR)(N62909-17-1-2159)