Received 7 June 2022, accepted 5 July 2022, date of publication 13 July 2022, date of current version 21 July 2022.

Digital Object Identifier 10.1109/ACCESS.2022.3190545

Toward Automated Security Analysis and

Enforcement for Cloud Computing Using
Graphical Models for Security
SEONGMO AN1 , ASHER LEUNG2 , JIN B. HONG 3, (Member, IEEE),
TAEHOON EOM 1 , AND JONG SOU PARK1
1 Department of Computer Engineering, Korea Aerospace University, Goyang 10540, South Korea
2 School of Information Technology and Electrical Engineering, The University of Queensland, Brisbane, QLD 4072, Australia
3 Department of Computer Science and Software Engineering, The University of Western Australia, Perth, WA 6009, Australia
Corresponding author: Seongmo An ([email protected])

ABSTRACT Cloud computing has become widely adopted by businesses for hosting applications with
improved performance at a fraction of the operational costs and complexity. The rise of cloud applications
has been coupled with an increase in security threat vectors and vulnerabilities. In this paper, we propose a
new security assessment and enforcement tool for the cloud named CloudSafe, which provides an automated
security assessment and enforce best security control for the cloud by collating various security tools.
To demonstrate the applicability and usability of CloudSafe, we implemented CloudSafe and conducted
security assessment in Amazon AWS. Also, we analyzed four different security countermeasure options in
depth; Vulnerability Patching, Virtual Patching, Network Hardening and Moving Target Defence. Virtual
Patching, Network Hardening and Moving Target Defence were determined to be feasible with regards
to deployment implementation for the project. Proof of concepts were developed demonstrating the
effectiveness of each feasible countermeasure option. These results indicate that the proposed tool CloudSafe
is effective and efficient in helping security administrators to select optimal countermeasures to secure their
cloud by conducting an in-depth security assessment.

INDEX TERMS Cloud computing, cloud security, graphical security models, security assessment.

I. INTRODUCTION These models provide the framework to collect security data

Cloud computing provides many beneficial factors over the and evaluate various attack scenarios of the network, as well
traditional networks, which enhance the productivity and as the capabilities to incorporate countermeasure selections.
performance of enterprises and individuals [1], [2]. But at However, automating the functionalities of those models in
the same time, it faces many security challenges and threats, the cloud can be challenging, as the privilege boundaries are
affecting the decisions of using cloud computing services more complex than the traditional networks.
significantly [3]. That is, potential cloud users need to Currently, much of the security analysis for the cloud is
consider various security implications before migrating their done manually by a security expert due to the complexity of
data and operations to the cloud computing environment [4]. enabling automation. In the manual process, however, a lot
Although there are various security mechanisms imple- of time is consumed and it can also introduce human errors.
mented for the cloud, their effectiveness must be evaluated Hence, automation is essential to reduce cost and time, as well
to fully understand the security posture of the cloud. One of as reducing human errors. There are many tools available
the widely used techniques is to develop a security assess- for assessing the security of networks [6]. For example,
ment framework using graphical security models [5], [6]. NAVIGATOR [7], MulVAL [8], and NICE [9] all have
functions to automatically assess the security of networks.
The associate editor coordinating the review of this manuscript and However, these tools require specific security details of
approving it for publication was Ali Kashif Bashir . the network, which may not be collectable in the cloud
This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
VOLUME 10, 2022 75117
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

due to privilege boundaries. Security information gathering attack paths by combining vulnerability, server configuration,
tools, such as NESSUS [10] and National Vulnerability policy rules, and security events. The generated attack path
Database (NVD) [11], are easily deployed in traditional is stored in the Neo4j-based database and provides the
networks as typically the whole network is under the system result of combining with the input query. Rizvi et al. [16]
administrator’s control. However, the cloud separates the proposed a framework for evaluating the security of the
privilege between different stakeholders (e.g., clients and cloud. They presented security evaluation rules to assess
service providers), limiting the access to security information the security using the developed security metrics (based on
that existing information gathering tools can access to. linear and nonlinear equations and fuzzy logic systems).
Hence, additional measures are needed to ensure that all this However, they only covered specific aspects of security,
information can be collected automatically to evaluate the such as interoperability, co-location, transparency, malicious
security of the cloud. insider and portability. Manzoor et al. [17] proposed a new
To address the aforementioned problems, our main motiva- security assessment model for the cloud using Petri Nets.
tion is to propose an automated cloud-based security analysis They profile the operational behaviour of the services in
framework named CloudSafe to evaluate the security of the the cloud operations, which are then used to evaluate the
cloud. In cloud computing, access to security information by security of the cloud operations in different layers. However,
existing security information collection tools is limited. For using Petri Nets can have a scalability problem, especially
that reason, we developed a framework that can automatically for the cloud where configurations can dynamically change
collect information about cloud computing and perform within a short period of time. There are many other graphical
security assessments. We present additional techniques to security models that could be used to assess the security of
collect security information from the cloud, which is then the cloud [5], [6], [18]. However, we must first specify how
stored in a database. For example, we used Security Group the security assessment could be carried out in the cloud
(SG), which is basic security method of AWS, to collect environment ensuring the data collection, processing and
reachability. As the security assessment framework in the evaluation, which has not been specified.
CloudSafe, we implement a scalable graphical security
model named Hierarchical Attack Representation Model B. AUTOMATE DEPLOYMENT OF SECURITY
(HARM) [12]. We further modify the functionalities of the COUNTERMEASURES IN THE CLOUD
HARM such that it will integrate with the security data Preda et al. [19] proposed an improved OrBAC
gathering interfaces we implemented for the CloudSafe. Our (Organisation-Based Access Control) model to allow for
prior work was published in [13], but we have substantially dynamic deployment of context-aware access control policies
extended the previous work as follows: for security devices. Their model allows security officers to
• We incorporated more security countermeasure dynamically deploy contextual OrBAC policies (essentially
approaches into our framework and evaluated their network traffic policies) over PEPs (Policy Enforcement
effectiveness; Points e.g. routers, firewalls, intrusion detection systems)
• We proposed optimal security countermeasure deploy- once specific contexts become active. Their work provides
ment strategy in the cloud with multiple countermeasure insight into methods for dynamically deploying security
selection options (i.e., multi variable optimization); countermeasures in the form of OrBAC policies in response
• We proposed a novel framework CloudSafe that extends to contextual and environmental system information [19].
its features to deploy optimal security countermeasures However, this is done in traditional networks where control
in the cloud; and over lower levels of network architecture is available.
• We experimented various security countermeasure As such this project proposes to find a method for deploying
selection scenarios in real-world cloud based on AWS. security countermeasures in the cloud, where underlying
The rest of the paper is structured as follows. Section II infrastructure is abstracted and granular control over physical
describes the related work on security assessment for the networking devices is unavailable.
cloud. Section III presents the CloudSafe framework with Kawashiro and Asano [20] patented a web server vulnera-
details on its architecture, configurations and workflow. bility patching method. Their program detects vulnerabilities
Section IV shows the results of using the CloudSafe in the of a web application server, acquiring vulnerability and
Amazon AWS. Finally, we conclude the paper in Section V. appropriate countermeasure information for patching, then
applying vulnerability patching directly to the web appli-
II. RELATED WORK cation. The patent describes the automation of the system
A. SECURITY ASSESSMENT OF THE CLOUD involving a web vulnerability patching device, method and
Bleikertz et al. [14] proposed a query and policy language program [20]. Their work is comparable to CloudSafe in
that could be used to specify desired and unwanted config- terms of automated data collection, storage, and assessment,
urations in the network. When an attack query is entered, and their methodology for deploying vulnerability patching to
it indicates whether an attack route exists based on the attack a web server is significant to the project. However, their work
graph. Noel et al. [15] proposed a scalable modeling frame- focussed on web application vulnerabilities on a traditional
work to create a predictive model for possible multi-step network. This must be transferred into the cloud, and for

75118 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

FIGURE 1. CloudSafe framework.

any type of software or operating system. Additionally, non- Although some work covers dynamic security countermea-
patchable vulnerabilities are not addressed in this paper. sure deployment in the cloud, differences exist as this project
Shameli-Sendi et al. [21] proposed a dynamic framework proposes to build on the original CloudSafe tool. A key
for optimal countermeasure selection for intrusion response difference is security countermeasure deployment integration
systems. The framework uses a multi-objective optimization with automated security assessment processes.
concept to maximize security benefit, while minimizing the
impact on users, services and deployment costs. The frame- III. CLOUDSAFE
work builds on top of Intrusion Detection Systems (IDS) that The details of CloudSafe tool is presented in this section.
detect exploits in a network, as a Intrusion Response Sys- CloudSafe follows the SaaS (Software-as-a-Service) frame-
tem (IRS) that protects a compromised network by selecting work that can perform cloud security analysis (i.e. a cloud
appropriate security countermeasures. From this perspective, service for cloud security). Figure 1 shows the overall process
CloudSafe is a Intrusion Prevention System (IPS) that of the CloudSafe framework. The proposed framework is
actively assesses the security posture of the network and implemented in the Amazon AWS (AWS for short), and it
selects security countermeasures to protect it. Firstly, in terms consists of two phases. Phase 1 collects information about the
of this project, their work confirms that vulnerability patching target cloud and stores the data used for the security analysis
and network traffic management (essentially host isolation) in a database. Then, the security is evaluated using the
are the most effective security countermeasures in terms of HARM (Hierarchical Attack Representation Model). HARM
maximizing security benefit while minimizing impact on is a security assessment model that can evaluate the security
users deployment costs. Secondly, much of the paper focuses posture of systems and networks against targeted attacks and
on the multi-objective optimization problem to select the denial of service attacks. Phase 2 generates and stores a
most optimal countermeasure which is out of scope of this new HARM model by modifying the security information
project proposal, but can assist in improving CloudSafe in the collected in Phase 1. In this way it can be seen if the security
future. posture of the cloud changes without changing the actual
Patil and Modi [22] designed a framework for vulnerability cloud configurations.
assessment and patching in cloud computing environments.
Their work is very relevant to this project proposal with A. PHASE 1
much of the assessment framework being comparable to Reachability of the cloud components in the security analysis
CloudSafe’s framework. However there are two issues with is essential information (e.g., the reachability of different
the paper. Firstly, it is assumed that the new joining of VMs virtual machines (VMs)). There are various tools for this
is the only source of introducing vulnerabilities which is purpose, but it is difficult to apply them in the cloud, because
inaccurate. Secondly, it is acknowledged that non-patchable the assessment tool may not have enough privileges to
vulnerabilities are not mitigated, as vulnerability patching is access such information. To solve this problem, we obtained
the only security countermeasure employed. They deal with Reachability using Security Group (SG), which is the basic
this problem by simply marking unpatched VMs as high risk security method of AWS. The SG controls access using IP
and continuously monitoring them. However CloudSafe aims and Port as packet filtering. The SG information is used to
to provide countermeasures for both patchable vulnerabilities generate the Reachability Graph (RG) by considering only
and non-patchable vulnerabilities to minimize risk. the allowed rules for inbound traffics. Figure 2 shows the
A significant amount of literature on security countermea- process of acquiring the reachability information from the
sures exist. However, most work focuses on evaluating their target cloud (i.e., the cloud environment to conduct security
effectiveness and optimizing for greatest security benefit. assessment) and storing it in the Network Database (NDB)

VOLUME 10, 2022 75119

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

OpenVAS software to connect to, along with credentials to

authenticate with the server, and the security groups to run
the scan on. The script will parse the security groups provided
and call AWS APIs to fetch the IPs of all EC2 instances
running inside those security groups and will subsequently
run the OpenVAS scan on those targets.
OpenVAS comes with a Management API (OMP) that
allows operations to be initiated within OpenVAS from
a remote machine. The script uses OMP to define the
targets, create and start the scan, continually check the
progress of the scan, and download the resulting scan report.
OpenVAS API requires authentication credentials defined in
the configuration file. Without the use of the script, these
FIGURE 2. Reachability scanning in phase 1.
operations have to be conducted manually from the OpenVAS
dashboard every time.
and Host Database (HDB) by parsing the SG to understand In addition to running the CloudSafe Java Program, the
the inter-VM reliability. Then, an RG is generated and stored script also provides a summary of the generated database and
in the NDB, and basic information of the host is generated in HARM object to the user as displayed in the final ’Security
the HDB. Algorithm 1 is used to populate the RG from SG, Analysis’ step (5) of the python script diagram. The Security
which uses information. The algorithm iteratively goes over Analysis is an extension to the CloudSafe Program written
the set of security rules to examine the reachability specified in Python that fetches the CloudSafe Program output to
in the SG, and continuously adding the new set into the RG. calculate security posture metrics for the user. An example
Through the process shown in Figure 2, information about of the output is provided in Appendix 5. Notably, the
the reachability and VMs included in the cloud is collected security analysis provides the user with the accumulative
and stored in the databases. However, the details of each risk of the target cloud (sum risk), and a host summary
VM are unknown. The details of the HDB are supplemented that identifies the risks and vulnerabilities for each host.
in the vulnerability scanning process. We use vulnerability The sum risk security metric allows the user to gauge
analysis tools to find vulnerabilities in each VM and store the general security posture of the target cloud. The host
them. This process is shown in Figure 4. The vulnerability summary allows the user to efficiently assess each host
analysis tool is used to scan all the VMs constituting the target and identify any critically vulnerable hosts, and furthermore
cloud, and the information is stored in the HDB. Vulnerability provide the vulnerabilities and affected ports of such a host.
scanning results include open ports, services provided, and Additionally, once a critically vulnerable host is identified,
vulnerabilities [23]–[25]. Algorithm 2 shows the process of the user can pair the host summary with the OpenVAS
collecting the vulnerability report. The module goes over vulnerability scan to learn more about the risk and impacts
every host (i.e., VMs) and conducts vulnerability scanning. of the vulnerability and possible solutions. The security
Then, the corresponding report is stored in the vulnerability analysis program can be edited further to provide more
database (VDB). We use open port information and vulnera- in-depth insights into the security posture of the target
bilities of VMs. If there are no vulnerabilities in the VDB, the cloud.
vulnerability information of the NVD (National Vulnerability As a result, the automation of the CloudSafe Framework
Database [11]) is retrieved and stored in the VDB. has improved the usability of CloudSafe by a signifi-
To improve CloudSafe, the process for scanning vulnera- cant degree. Given the dependencies have been met, and
bilities in the target cloud and generating the security posture configuration input provided, a single command can be
assessment was automated. As an automated vulnerability used to conduct vulnerability scanning, provide security
scanning tool, the need for manual intervention impedes posture assessments and summaries, and possible solutions of
the tool’s ability to effectively discover vulnerabilities vulnerable hosts to users. The ability to do so in an automated
continuously over time. A python script was created to fashion shows insight into the potential of CloudSafe to
integrate each step in phase 1 in an automated fashion. Python secure cloud environments. The script was created to provide
was chosen as the scripting language due to its popularity a proof of concept and was developed to a minimum viable
and general purpose functionality. Java was considered, as the product level.
original CloudSafe Program was written in Java, however it With collected reachability and vulnerability data, we can
lacked the functionality to easily call the OpenVAS APIs to generate the HARM as shown in Figure 5. The generated
run vulnerability scans. HARM is stored in the HARM object DB, which is then used
The diagram below illustrates the steps and actions to compare the changes in the security of the cloud in phase 2.
performed by the script. But this information could also be used later to carry out other
The inputs required to initiate the scan include a config- off-line security assessments. Finally, the security analysis
uration file that identifies the IP of the machine running the result from the HARM is provided to the user.

75120 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

FIGURE 3. Phase 1 python script diagram.

Algorithm 1 Security Groups to Reachability Graph Parser

procedure Generating RG from SG(SG, NDB, HDB)
Init RG
for All Security Rule in SG do
if RG 6 3 SG.host then
Add SG.host to RG
Insert SG.host to RG
end if
Add SG.reachability to RG
end for
FIGURE 5. Security assessment in phase 1.
Insert RG to NDB
end procedure
Algorithm 2 Vulnerability Scan Report Parser
procedure Analyse Vul
Report(Report, HostID, HDB, VDB)
Init Host
Insert Time, OS, PortstoHDB(HostID)
for all vulnerabilities in report do
V ← vulnerability
Add V to Host
if VDB 63 V then
Insert V to VDB
end if
end for
Insert Host to HDB
end procedure
FIGURE 4. Vulnerability scanning in phase 1.

Figure 6 represents the entire DB schema. The framework name of the vulnerability it has. The VDB stores the details
used MongoDB and a NoSQL database. Because there are of each vulnerability. CVSS, Risk, and Impact information
many multi-value elements in the framework, the NoSQL are parsed by the NVD and stored in the database, and
database is easier to store than the RDB. However, the the probability is obtained from the Common Vulnerability
figure is shown using the RDB schema because there is no Scoring System used by the NVD. The attack cost value
proper way to express the structure. NDB stores the VMs is saved as void because there is no way to calculate it
constituting the network and stores the reachability of each automatically (i.e., it will rely on the monetary values of the
VM. HDB stores information about each VM. The main assets in the cloud). Hence, the user can directly enter the cost
information is the IP address of the host, open ports, and the value as appropriate.

VOLUME 10, 2022 75121

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

Algorithm 3 Generating the HARM

procedure Generating HARM from
DB(NDB, HDB, VDB, HARMobjectDB)
Init HARM
Read NDB
for All hosts in NDB do
Add host to HARM
Read HDB
for All vulnerability in HDB do
Read VDB
V ← vulnerability FIGURE 7. HARM modification and comparisons in Phase2.
Add V to HARM
end for
ADD Rechability to HARM improves the security posture of the cloud. To achieve
end for this, different countermeasure solutions are compared and
Insert HARM to HARMobjectDB evaluated their effectiveness by introducing security changes
end procedure using the HARM.

C. PHASE 3
1) SECURITY COUNTERMEASURE ANALYSIS
A. IMPACTS OF THE CLOUD
Prior to selecting possible security countermeasures, the
impacts of using the cloud on cyber security need to be
taken into consideration. The differences between cloud and
traditional networks affect which security countermeasures
may be used and how they are deployed. Despite differences
between cloud providers, this analysis will focus on how
AWS offers their cloud services. The primary impacts of the
cloud to cyber security include:
• No access to physical infrastructure
• Differences in traditional and cloud networking
• Dynamic nature of the cloud
• Virtual machines consistently start and terminate on-
demand
A key implication of migrating to the cloud means
that cloud users have no access to physical infrastructure.
FIGURE 6. DB schema. As a result, physically installing security solutions are
not possible, for example, physical firewalls and network
monitors. Additionally, to optimize the benefits of using
B. PHASE 2 the cloud, cloud users dynamically adjust their workloads
In order to improve the security of the cloud, we can deploy to adapt to changing requirements and demands such as
security solutions based on the security assessment of the increases in network traffic. This introduces the dynamic
cloud we generated from Phase 1. However, it takes many nature of the cloud, in which virtual machines consistently
resources to perform these tasks. Consequently, the service start and terminate on-demand. As a result, the security
can also be stopped in the process. To solve this problem and attack surface and thus security posture of a target cloud
test the security of the cloud, we propose Phase 2 that can regularly changes over time. In terms of security, security
create a new security model of the cloud by modifying the assessment methods need to take into account the temporal
HARM configuration that was previously stored in the DB and diverse nature of cloud attack surfaces. Furthermore,
and evaluate their effectivenesses. security countermeasures and their behaviour in the cloud
Figure 7 shows the whole process of Phase 2. In this need to be considered.
phase, NDB, HDB, and VDB are modified and saved in the
DB. As a result, a new HARM model is generated, and the B. COUNTERMEASURE TYPES
security analysis result of the new HARM model is provided Security countermeasures are a highly researched field,
to the user with a comparison report with the original HARM with a wide variety of solutions documented for all types
model generated in Phase 1. Phase 2 works recursively to of vulnerabilities. A security countermeasure is generally
change the cloud configurations in a direction that gradually deployed to mitigate the risk from a single vulnerability.

75122 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

As mentioned previously, vulnerabilities can be classified 3) Select security countermeasure to evaluate

into two different categories: 4) Manually deploy selected security countermeasure
• Patchable vulnerabilities 5) Run CloudSafe to assess security posture of new cloud
• Non-Patchable vulnerabilities environment
Patchable vulnerabilities are those that have available 6) Analyse effectiveness of security countermeasure by
fixes/patches. These fixes are usually software updates, comparing security posture using the following criteria:
operating system upgrades, software configuration changes • Attack Probability (OR & MAX)
and security bug fixes. Non-patchable vulnerabilities are • Security Risk
those that have no known available fixes, and thus mitigation – Sum Risk
actions need to be taken. – Max Risk
Taking into account the impacts of the cloud mentioned • Attack Path Lengths
prior, the security countermeasures that can be deployed into 7) Repeat the previous steps iterating through each
the cloud are: security countermeasure option
• Network Level Security Controls
• Host Level Security Controls D. TESTBED
Network level security controls involve changes in the net- Below is a list of cloud testbed architectures I initially
working abstraction of the cloud. For example, manipulating proposed to analyse security countermeasures on with
the network topology using security groups in AWS to CloudSafe:
increase the complexity of attack paths to vulnerable hosts. • 3-Tier Web Application (Web Server, Web Applica-
These security controls have no impact at the host level, and tion, Database)
therefore usually do not resolve a vulnerability, but rather • Streaming Service (FTP, Streamer, Vod Bucket)
reduce risk. Host level security controls involve directly • Web Application with Bastion Host
applying a patch to a vulnerable host. These include changes • Content Distribution Network (CDN)
at the operating system or application level of a host. Host Each cloud application architecture has different impli-
levels security controls generally resolve a risk completely cations on the security posture of the cloud. Different
within the system, while network level security controls architectures will have different vulnerabilities, attack paths
mitigate risk to an acceptable level. Thus host level security and attack surfaces. Due to project schedule constraints and
controls are usually favored when choosing between security the prioritization of security countermeasure deployment,
countermeasures. However, they often require downtime to a the 3-tier Web Application architecture was used for the
service which may result in high costs or is unacceptable in entirety of the project due to its simplicity. Theoretically,
some cases. The consideration of costs to deploying security the deployment of a security countermeasure for the same
controls is not taken into account for this project. vulnerability will have the same affect within different cloud
architectures on the host level. Therefore, the use of a single
C. COUNTERMEASURE ANALYSIS APPROACH testbed is reasonable and acceptable for the purposes of this
Analysis of security countermeasures will occur by identi- project. The use of multiple architectures would only offer the
fying the result, requirements, methods, and difficulties of ability to perform different vulnerability patching methods.
deployment. This enables the feasibility of implementing a The testbed will be used to analyse the effectiveness
solution to deploy the security countermeasure to the cloud. of security countermeasures. Figure 8 displays how the 3-
The effectiveness of a security countermeasure will be ini- Tier web application architecture will be set up in AWS.
tially tested by manually implementing the countermeasure An internet gateway will provide the subnet access to the
into a cloud testbed for this project when possible, otherwise internet; however, each security group will control inbound
the theoretical outcome will be used. network traffic with granular control. The use of three
The security countermeasures that will be evaluated are: security groups in AWS is equivalent to having 3 subnets on
• Vulnerability Patching a LAN from a networking perspective:
• Virtual Patching • Web SG - will allow http and https (port 80 and 443)
• Network Hardening communication with the internet
• Moving Target Defence • App SG - will allow traffic from the Web SG on port
These are generalised security controls applicable to almost 8080 (application specific)
any cloud environment that uses the cloud provider’s main • DB SG - will allow traffic from the App SG on port 3306
compute offering and networking abstraction. In this case, (database port)
EC2 instances for compute workloads and Security Groups • All SG - will allow ssh (port 22) communication from a
for networking. specific IP address range
Evaluation of security countermeasures will occur through As illustrated in figure 8, there will be two instances to
the following steps: mimic web servers, two instances for application servers, and
1) Setup AWS testbed a single database instance (An instance is a virtual machine
2) Run CloudSafe phase 1 on testbed and determine initial within AWS). These instances will each be running purposely
security posture vulnerable containers (software), so that appropriate security

VOLUME 10, 2022 75123

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

TABLE 1. NMap scan results.

FIGURE 8. Testbed architecture.

FIGURE 9. AWS CloudSafe instances.

countermeasures can be deployed. The container that will be

used is a docker image running a version of Metasploitable.
Metasploitable is an intentionally vulnerable linux virtual
machine which is widely popular for security penetration
testing activities. Table 1 displays the standard output of an
Nmap scan on a Metasploitable virtual machine. Nmap is
an open source network scanner, that can scan an endpoint’s
ports to discover the software that is likely present on
the host. It is a widely used penetration testing tool to
discover vulnerable ports of a network. From the scan
result, notable software on the Metasploitable virtual machine
include ssh, http, and postgresql that have vulnerabilities.
For variety, the web server and database instances will be
running Metasploitable 2, and the application will be running
Metasploitable 3.
Figure 9 displays the instances running within the
AWS console. Web server instances are named ’cloudsafe-
a-web-metasploitable2’, application instances are named
’cloudsafe-a-app-metasploitable3’, and database instances FIGURE 10. AWS CloudSafe security groups.
are named ’cloudsafe-a-db-metasploitable2’. Additionally,
the figure shows the instance running OpenVAS, and another
running MongoDB used by CloudSafe for vulnerability and were configured for the testbed initially and their relationship
host data storage. Figure 10 illustrates the security groups that between each other. The specific network traffic ingress rules

75124 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

were changed consistently over the course of the project for a instance running vulnerable database software). As a
testing. result, although the vulnerable software is still running, the
Table 5(a) displays the raw results of running the auto- vulnerability cannot be reached thus blocking an attacker.
mated scanning program on the initial testbed environment Subsequently, virtual patching will also block legitimate
within AWS. These results are used as a benchmark users or dependent software from reaching the service, ren-
for evaluating security countermeasure effectiveness later. dering the port/service unusable. Virtual patching is however
As determined from the program, the accumulative risk for useful for newly discovered non-patchable vulnerabilities as
the initial testbed is 268.53, with a total of 28 vulnerabilities a good short-term solution until a patch becomes available.
within the whole system. The accumulative risk is calculated
from all vulnerabilities found on all hosts. As such, the risk G. NETWORK HARDENING
value from a specific vulnerability present on multiple hosts
Network hardening is the process of locking down exposed
will be higher in the end. This is reasonable as a vulnerability
ports within the networking abstraction of the cloud. As such
found throughout an entire system is arguably higher risk
it is very similar to virtual patching in terms of its behaviour
than a vulnerability only on a specific host, as the likelihood
of allowing vulnerable software to exist, but denying access
of vulnerability exploitation is multiplied. For simplification
to it. Network hardening is usually a method for ensuring
purposes, attack surface and attack path calculation are not
best security practices within cloud environments, but can
conducted within this project. From the host summary, the
also be deployed as a countermeasure to a newly discovered
host type can be identified from the vulnerable ports. The
vulnerability. Network Hardening is a network level security
database instance has port 3306 exposed, the application
control that manipulates the networking within the cloud and
instance has port 9200 exposed, and web server instances
does not affect hosts directly. In AWS, this include Network
have all ports exposed by the security group ingress rules.
Access Control List (NACL) manipulations, and Security
E. VULNERABILITY PATCHING
Group (SG) manipulations. NACLs and SGs have essentially
the same behavior, however, the implications to networking
Vulnerability patching is the action of applying patches or
between hosts are different. For the purposes of the project,
fixes to vulnerable hosts or their affected software. There
Security Groups will be focussed on. Similarly to virtual
are numerous types of patching that can be applied to hosts
patching, host hardening can mitigate risk completely and is
as it is a relatively general term. Examples include updating
a good short-term solution until a vendor fix is available.
software, changing operating system versions, installing
Using security groups, which provide granular control over
security bug fixes, or changing software configuration.
ingress traffic to instances, a system administrator can lock
Vulnerability patching is a host level security control that
down access to certain ports to certain IP address ranges
addresses the vulnerability directly.
using CIDR blocks. By doing this, services can be accessed
The security control generally resolves a vulnerability
only from trusted IP ranges, significantly reducing the risk of
completely and mitigates its risk from all affected hosts.
attackers being able to exploit any vulnerabilities. Assessing
If applied, the countermeasure can reduce the possible attack
the security posture of the environment after doing so is more
paths within the network by blocking attackers from hosts
difficult as attackers may use IP spoofing or other techniques
deeper within the network. As a result, the overall security
to overcome this.
posture should improve significantly after implementing
vulnerability patching. On the other hand, patching directly
on hosts may result in service downtime which may lead H. MOVING TARGET DEFENCE
to further costs. Downtime can be avoided depending on Moving Target Defence (MTD) is a relatively novel security
the deployment method, however. Additionally, a singular countermeasure with less literature available than other
patch may only be valid for a specific vulnerability on security controls. MTD involves changing aspects of the
specific software versions, operating systems, and further system to present attackers with a varying attack surface,
dependencies. making it much more difficult for an attack to exploit a
vulnerable system. The hope is that in the time it takes for
F. VIRTUAL PATCHING an attacker to learn the properties and construct the exploit,
Virtual patching is the action of virtually applying a patch the system would have changed enough by the time the
to a vulnerability on a host directly. Various methods may attacker can launch the exploit [26]. The effectiveness of
be implemented to achieve virtual patching, however, they MTD has been debated heavily, however, MTD is generally
should have the same effect on the host. Virtual patching more effective in complex systems, with its effectiveness
leaves alone the affected software and manipulates the host diminishing heavily within simpler systems.
in such a way that the vulnerable software is unreachable. The implementation of MTD can provide an extra layer
Virtual patching is a host level security control that addresses of security to a cloud environment alongside additional
the vulnerability directly. security controls. However MTD requires a large amount
An example includes disabling the port on a host associated of overhead in implementation that is heavily dependent on
with a vulnerable software (e.g., closing port 3306 for system implementation. MTD is especially useful against

VOLUME 10, 2022 75125

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

Advanced Persistent Threats (APTs) that require time and perform a rolling update on all machines in a system
planning to coordinate and launch [26]. to their latest versions. For this project, Ansible would
be able to perform vulnerability patching on affected
2) SECURITY COUNTERMEASURE DEPLOYMENTS machines or be able to apply security group changes
The proposed Phase 3 of CloudSafe, involves the deployment to AWS. Additionally, Ansible is agentless meaning
of security countermeasures to the cloud in an automated minimal setup is required allowing for simplicity of use.
programmatic fashion. Phase 3 should integrate with the rest • Jenkins - Jenkins is an open-source automation server.
of the CloudSafe Framework and should take the output from It is a popular software enabling DevOps practices
phases 1 and 2 as input into the security countermeasures. with CI/CD (Continuous Integration & Continuous
As an initial proposal regarding the framework, the steps Delivery). Jenkins could be used in this project to
for phase 3 include: integrate DevOps practices and allow for continuous
1) Identify security countermeasure options according to delivery of security countermeasures to the cloud. The
vulnerabilities discovered use of Jenkins requires the deployment of a Jenkins
2) Determine optimal security countermeasure deploy- server potentially on an EC2 instance. Due to this
ment order overhead in implementation the potential for use of
3) Deploy security countermeasure to target cloud Jenkins is lowered.
Step 1 takes into account the output from the CloudSafe • Packer - Packer is an open-source tool that automates
Program in addition to the OpenVAS vulnerability report to the creation of any type of machine image. Packer
determine the possible security countermeasure options. Step uses automated scripts to install and configure software
2 relates to optimal security countermeasure selection and within Packer-made images. Packer can easily be used
ordering from the set of possible options. This step involves to apply vulnerability patches to AMIs, however another
solving a multi-objective security hardening optimization tool will be required to deploy the resulting images such
problem. This is out of scope for the project. Step 3 is the as AWS CLI or Ansible. For this project, Packer can be
primary focus for this report. The security countermeasure used to generate images used for the testbeds to ensure
option analysis conducted within this project provides an consistency.
initial foundation for possible security countermeasures and • Containers (Kubernetes & Docker) - Containers are
their feasibility. This section details the countermeasure packages that include a software’s code and all its
deployment implementations for each option deemed feasible dependencies, that can be run quickly and reliable in
within the scope of the project from the analysis. The any computing environment. Docker is a container run-
countermeasure options implemented as a result of the time engine, and Kubernetes is a container orchestration
analysis include: platform. The use of containers would simplify the
• Virtual Patching process of creating and running images. Containers
• Network Hardening could be used to simplify the setup of testbeds for
• Moving Target Defence evaluation security countermeasure effectiveness.
Assumption: For any system, the deployment of security • AWS CloudFormation - CloudFormation is an AWS
countermeasures requires administrator access to the cloud service for provisioning and managing AWS resources
resources. Therefore agent-based software and the instal- as code (Infrastructure-As-Code). It provides a way to
lation of tools into the administrator’s cloud for security model your applications or cloud environments into
countermeasure deployment is within scope of the project. re-usable and version-controlled templates. The use of
Below is a list of proposed tools and software that were CloudFormation would provide a simple method to
taken into consideration to implement the deployment of implement AMI updates and security group changes,
security countermeasures or be used in the project: however, would require CloudFormation as to be part
• Python - Python is an interpreted, high-level, general- of the underlying infrastructure. CloudFormation could
purpose programming language. Python is widely be used to simplify the set up and management of the
popular and used for many purposes. For this project, testbed.
python is the programming language of choice for
implementing scripts due it its readability and simplicity. A. VIRTUAL PATCHING
For a deployment workload, performance and speed is To deploy virtual patching, an ansible script was created to
not an issue, as such a general-purpose programming programmatically disable a vulnerable port on all specified
language is well within reason. hosts automatically. The ansible script has the following
• Ansible - Ansible is an open-source software provision- requirements:
ing, configuration management, and orchestration tool. • Anisble
Using Ansible, administrators can effectively manage • Python
entire networks, application life cycles, and cloud envi- • SSH access to targets - Private Key
ronments, from simple provisioning tasks to complex • AWS API Permissions
workflows. For example, Ansible can automatically • AWS SDK (boto3)

75126 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

The inputs to the ansible script include: instance defined periodically. Periodically changing the IPs
• Port to disable of all instances within the environment would present a
• Security Group of instances to apply virtual patching to potentially dynamically changing attack surface for attackers.
The simplified steps of the ansible script are as follows: Note: The python program is purely a proof of concept for
1) Parse inputs demonstrating a changing attack surface and is not practical
2) Using AWS API calls -> determine all instances and to deploy.
their IPs within the security groups inputted The use of MTD in this case would require deployment
3) SSH into each instance using private key defined in of an external load balancer to consistently point to the
ansible configuration changing endpoint locations, or the deployment of a service
4) Using iptables module -> create rule to drop packets discovery application to enable consistent communication
incoming from inputted port on each instance between services with dynamic endpoints. The python script
The ansible script can be initiated using the command
takes advantage of a certain behaviour within AWS, being
line with a single simple command. This implementation
that when an elastic IP is attached then disassociated from an
is a proof of concept that programmatically applies virtual
instance, the instance IP will reset to a random IP within the
patching to a set of hosts. Although the inputs are provided
AWS IP pool. By doing this periodically for each instance,
manually by a local configuration file, they can be inputted
MTD can be demonstrated.
programmatically and integrated with output from phase
1. Additionally, the method of defining which hosts to IV. EXPERIMENTAL ANALYSIS
apply virtual patching to can be modified to provide better For the experiment, we set up two different cloud testbeds
flexibility for the security countermeasure option. to demonstrate the applicability and practical use of the
CloudSafe tool. The two target clouds were implemented in
B. NETWORK HARDENING
the AWS. The AWS provides an interface to monitor when
To deploy networking hardening a python program was security policies are applied. So we set up the testbeds in the
created to programmatically manipulate Security Groups to AWS to check the status of the cloud using that interface.
lock down vulnerable ports and deny access. Due to the The first is implemented in three tiers of Web, App, and DB,
difficulties on implementing a security group manipulation and the second one is implemented as a streaming server. The
solution stated in the analysis prior, this implementation is a configuration of the testbeds is detailed in Table 7. We show
proof of concept only and requires further development. The how the two phases described in the previous section are
python program requirements include: applied in the two cloud testbeds in the following subsections.
• Python
For simplicity, two security metrics (attack probability and
• AWS SDK
security risk) are used to demonstrate the application of
• AWS API permissions
CloudSafe tool. However, other security metrics can be used
The inputs to the python program are:
• Host summary output from automated scanning program
to evaluate the security posture as well, as shown in [6].
The steps of the python program are as follows:
• From the host summary -> Parse each host’s A. APPLYING PHASE 1 IN THE TESTBEDS
vulnerable ports Figure 11 shows the connections between the AMI and SG in
• Using AWS API -> Retrieve all ingress rules within testbed 1. The DB only allows connections from the App, and
each instance’s security groups the App only uses connections from the Web. The Web allows
• Map each host’s vulnerable port to any and all ingress connections via HTTP and https. All AMIs allow connection
rules they match and are associated with of a specific IP from port 22, which is for using SSH.
• Iterate through all ingress rules have that vulnerable As an illustrative example, Figure 12 shows the HARM
ports and revoke using AWS API call model generated for testbed 1. Potential attack possible paths
A key problem met when developing this solution was the are calculated in HARM. Users can also retrieve the graphical
need to map each host’s vulnerable ports to all ingress rules view of the HARM to understand the cloud components and
they matched and are associated with programmatically. The their security relationships. We omit the illustrative example
issue was that instance may have multiple Security Groups, for testbed 2 due to the limited space.
and Security Groups may have multiple ingress rules, that Table 2 shows the security analysis results for testbed 1,
may have port ranges, and rules that overlapped. The program and Table 3 for testbed 2. They include the security
needed to identify all vulnerable ingress rules and revoke analysis results from both Phase 1 and Phase 2, which
them. This was solved by individually iterating through each can be compared directly. The CloudSafe tool generates
instance and it’s security group ingress rules and determine the security report using various security metrics, and other
any vulnerable ingress rule and storing that within a mapping. relevant metrics, not only security related (e.g., performance,
reliability etc), can also be implemented as additional metric
C. MOVING TARGET DEFENCE modules and integrated with the HARM. By generating those
To deploy MTD to the target cloud, a python program was security reports, we can easily compare different security
created to programmatically change the public IPs of each aspects of various cloud environments. One note is that using

VOLUME 10, 2022 75127

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

FIGURE 12. HARM for testbed 1.

TABLE 2. Security analysis results for testbed 1.

TABLE 3. Security analysis results for testbed 2.

FIGURE 11. Relationship between AMIs & SGs of target 1.

the HARM, the attack cost and the return on attack calculation
functions require the attack cost to be specified in the DB.
As NVD does not provide this cost, this function is not used
in this study (however, it can be calculated if specified by the
user). Next, we consider applying security countermeasures
to compare how the security posture changes and evaluate the
changes using CloudSafe. changes using CloudSafe when countermeasures are
deployed. One way to optimize the vulnerability patching
B. APPLYING PHASE 2 IN THE TESTBEDS is to prioritize the set of vulnerabilities to patch. To do
An example countermeasure selection we deploy here is this, we compute the prioritized set of vulnerabilities (PSV)
vulnerability patching, to show how the security posture as specified in [27]. The PSV is a method that can be

75128 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

The result shows that for testbed 1 (i.e.,

Figures 13(a) and 13(c)), patching more vulnerabilities would
decrease the risk and the probability of attack success in a
consistent trend. That is, the amount of reduction is roughly
equivalent when a vulnerability is patched every time. On the
other hand, the effectiveness of patching vulnerabilities
is different from testbed 2, where the reductions in the
risk and the probability of attack success are less effective
compared with testbed 1. Although there is a sharp reduction
when patching 3 vulnerabilities, there is no significant
reduction when more vulnerabilities are patched. CloudSafe
provides such security analysis for users to view and
understand how the security posture can change when
different countermeasures are applied in the cloud.

C. APPLYING PHASE 3 IN THE TESTBEDS

1) VULNERABILITY PATCHING
Results: As explained previously, vulnerability patching
should generally resolve a vulnerability and its associ-
ated risk completely. Generality is used in this case due
to the various types of patching solutions available for
different vulnerabilities. A few options for testing the
effectiveness of vulnerability patching was considered for the
testbed:
• Replacing the web server Metasploitable 2 instances
with new instance running nginx (web server software).
• Replacing the application Metasploitable 3 instances
with new instance running application software.
• Replacing the database Metasploitable 2 instance with
new instance running latest postgresql version.
In essence, each of these options are considered vulnerability
patching. For testing, the replacement of the database
Metasploitable 2 instance was chosen due to simplicity. The
steps for testing in AWS are listed below:
1) Terminate database instance
2) Instantiate new instance running Amazon Linux 2 AMI
(standard image)
3) Install latest postgresql software version using default
package manager (yum)
The security posture of the new cloud testbed environment
was then assessed by running the automated scanning
program again. Consolidating the statements made prior,
FIGURE 13. Changes in security posture when patching vulnerabilities
using PSV. (a) and (b) show the risk report for testbed 1 and testbed 2, the patching successfully removed the vulnerabilities from
respectively. (c) and (d) show the probability of attack success report for the database instance and system. The results of the new
testbed 1 and testbed 2, respectively.
scan are displayed in Table IV-B(b). The summated risk
of the new environment was 234.1, a significant decrease
applied to improve the security of a network using the from 268.53 prior to implementing the patch. From the host
HARM. For our implementations, we use the exhaustive summary, the new database host ’10.50.16.28’ running the
search (ES) algorithm method among other PSV algorithms. latest PostgreSQL version had no vulnerabilities with a 0 risk
The ES algorithm uses the risk and cost values to prioritize metric and no vulnerable ports discovered from the scan.
vulnerabilities to be patched in the cloud testbeds. Table 6 Requirements: Regarding implementing vulnerability
shows the PSV ranking of the testbeds, and the result patching as a security countermeasure, the requirements and
of applying PSV to the testbeds is shown in Figure 13. dependencies are as follows:
We eliminated the vulnerability sequentially from ES1 to ES5 • Ability to perform patching on machines either directly,
respectively, and the results show the gradual reduction in the or on a separate security environment.
risk and the probability of attack success. • A patch is available - only for patchable vulnerabilities

VOLUME 10, 2022 75129

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

TABLE 4. Phase1 execution time.

Note: These requirements are for general vulnerability 2) VIRTUAL PATCHING

patches. They may not hold for some patching methods. Results: Similarly to vulnerability patching virtual patching
Different methods may have additional dependencies. theoretically mitigates a vulnerability completely. To test the
Methods: For the purpose of assessing the feasibility of effectiveness of virtual patching as a security countermea-
implementing a vulnerability patching solution, the following sure, any of the vulnerable ports listed in the host summary
methods were proposed: of the initial testbed can be disabled manually, directly on the
• In-place patching host. The host and port tested was port 9200 on the application
• AMI patching instances. The steps for testing in AWS are listed below:
• New instance 1) SSH into instance with private key
2) Using iptables package (linux firewall implementation)
In-place patching involves directly accessing an instance and
to drop any incoming packets from the selected port
applying the patch using command line. This method caters to
(9200)
software updates, and configuration changes. AMI patching
is useful for applications that are instantiated using AMI’s After running the automated scanning program to determine
(Amazon Machine Images, essentially virtual images). AMI the security posture of the new cloud testbed environment, the
patching is conducted by updating an AMI, and through virtual patching successfully removed the vulnerability from
rolling updates, the vulnerable hosts are replaced by new the environment, and consequently any access to the service
instances running the updated AMI. A new instance is simply entirely. The results of the security posture assessment are
done by replacing a vulnerable host with a new instance as displayed in Table IV-B(c). The accumulative risk of the new
done within the test. environment after virtual patching was 208.11, a significant
Difficulties: The difficulties regarding implementing a decrease from the initial sum risk of 268.53. From the host
vulnerability patching solutions are listed below: summary, it can be observed that port 9200 is no longer a
vulnerable port within the network. Therefore signifying that
• Different vulnerabilities have significantly different the virtual patching successfully worked as intended.
patching methods (i.e. simple rpm update, security bug Requirements: Regarding implementing virtual patching
fix download and install, password update, and complex as a security countermeasure, the requirements are listed
configuration change) below:
• Different systems have different implementations (not
all AWS application environments may implement AMI • Ability to perform patching on machines directly
usage) • Patch is unavailable
• New vulnerabilities are regularly discovered and may • AWS API permissions for scripting purposes
have new vulnerability patching methods Methods: In terms of the method for virtual patching as
• Patches may have complex dependencies that may be a security countermeasure as part of Phase 3, a script to
required to be resolved before application edit instance firewall automatically is proposed as a proof of
Feasibility: As a result of the difficulties outlined above, concept. For the proof of concept, it is assumed that instances
the potential of implementing a vulnerability patching run on either Linux or Ubuntu distributions.
solution as a security countermeasure option for Phase 3 will Difficulties: The difficulties regarding implementing a
not be undertaken. Regarding vulnerability patching for virtual patching solution are:
Phase 3, from the output of Phase 2, if a vulnerability • Need to determine services dependent on vulnerable
has a patch available, the vulnerability patching can be software if any - this may impact the ability to deploy
suggested as a security control to improve the security posture virtual patching
as a solution. Using output from OpenVAS vulnerability • Need to understand impact of virtual patching to
reports, the suggestion could include the patch type, and workload
patch resources and location to further assist in vulnerability • Operating System’s may have different firewall imple-
patch application. mentations

75130 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

TABLE 5. Applying phase 3 raw result.

Feasibility: In conclusion, the implementation of the 3) NETWORK HARDENING

method to deploy virtual patching as a security countermea- Results: As network hardening has the same behaviour as
sure as part of Phase 3 is within the scope of the project. virtual patching, but is applied to the network level, network-
The implementation will be a proof of concept that will ing hardening also theoretically mitigates risk from locked
have assumptions regarding the cloud environment and the down ports completely, while also consequently deny all
application. access to any services behind the port. To test to effectiveness

VOLUME 10, 2022 75131

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

of network hardening the security group of the web server Requirements: To implement MTD as a security counter-
instances will be locked down to only expose ports 22, 80 and measure for Phase 3, the only requirement is access to AWS
443 (standard web server ports). Looking at the host summary credentials and AWS API permissions.
of the initial testbed environment, the web server instances Methods: The diversity in the attack surface can be
have a several vulnerable ports contributing significantly to created through multiple methods. Alternatives include
the accumulative risk. Conducting this network hardening diversity in terms of the software and applications within the
should reduce the sum risk of the environment greatly. The system, and diversity through rotational changes in endpoint
steps for testing in AWS are as follows: locations.
1) Access AWS console Difficulties: The difficulties regarding implementing a
2) Navigate to the web server security group MTD solution as a security countermeasure option for
3) Remove the unnecessary ingress traffic rules Phase 3 include:
4) Add ingress from any IP address for TCP ports 22, • Systems with complex network topologies
80 and 443 • Dynamicity needs to be a component developed into the
Assessing the security posture of the new cloud environment system
provided in Table 5(d) confirms that network hardening • Systems may require static components (e.g. static
successfully resolves the risk from any locked down port endpoints)
completely. The results of the security posture assessment • Large overhead in implementation
display a accumulative risk of 59.29, a major reduction from • Countermeasure effectiveness is difficult to assess
268.53 initially. Examining the host summary consolidates • Security Groups may be implemented differently for
the statements made prior, as the web server instances only different systems
have one vulnerable port
Requirements: To implement network hardening as a Feasibility: Despite difficulties regarding MTD, it is
security countermeasure for Phase 3, the only requirement is feasible to implement a simple MTD solution as a security
access to AWS credentials and AWS API permissions. countermeasure option for Phase 3. Considering the scope
Methods: As mentioned briefly previously, the two of the project and constraints, a simple proof of concept is
methods to implementing network hardening in AWS are implementable.
though NACL manipulation or SG manipulation. Security
Group manipulation can be performed either manually in the D. OVERHEAD
AWS console, a program using AWS Software Development To understand the performance overhead using CloudSafe,
Kit (SDK) or through a script using AWS Command Line we measure the time take in Phase 1. The time taken using
Tool (CLI). the CloudSafe tool on testbed 1 was measured and the mean
Difficulties: The difficulties regarding implementing a value was used from 10 measurements. Table 4 shows the
network hardening solution include: overhead of gathering the data to populate the DBs. It shows
• Systems with complex network topologies will increase that most tasks can be completed reasonably quickly (within
difficulty exponentially a matter of a few seconds), while the biggest bottleneck is
• Required services and their exposed ports need to be the vulnerability scanning of VMs. One approach to improve
understood the vulnerability scanning time is to reduce the port range
• Security Group rules may be implemented differently to scan, but vulnerabilities outside the measurement range
for different applications/systems would not be included in the analysis. Another approach is to
• Vulnerable ports may be allowed by multiple ingress parallelize the vulnerability scanning using the cloud, which
rules in multiple security groups we will investigate in our future work.
• Ingress rules may contain port ranges - changes need to Next, we measure the computational overhead using
preserve those ranges CloudSafe. The use of the vulnerability analysis tools is
Feasibility: Although there are several difficulties and the only factor that affects the VM when using CloudSafe.
nuances regarding a solution for network hardening, the Figure 14 shows the load on the CPU and the network of the
design and implementation of a proof of concept using the VMs when using CloudSafe. All TCP/IP ports were scanned
AWS SDK is within the scope of the project. and the load was measured in 1-minute increments. During
the measurement, CPU usage increased by up to 11 percent,
4) MOVING TARGET DEFENCE and the network had a maximum input of 5,042 bytes per
Results: As mentioned above, the effectiveness of MTD as a minute and an output of 416 bytes. During the tool usage
security countermeasure is difficult to gauge. For the scope period, the cumulative input was 11,163 bytes and the output
of this project, the testing of MTD on a simple 3-tier web was 1,234 bytes. Network load was not large, but the CPU
application architecture is unreasonable. Additionally, with utilization increased significantly. There is a need to adjust
the CloudSafe framework and simple security metrics used the scan options depending on the host’s CPU performance
for this project, determining the effectiveness of MTD is out or the role. On the other hand, disk reads and writes were
of scope. almost unchanged.

75132 VOLUME 10, 2022

S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

TABLE 6. PSV using ES method for testbed 1 (top 6). TABLE 7. AWS resources for the target clouds.

TABLE 8. Security assessment cloud resource.

TABLE 9. Vulnerabilities in AMIs.

FIGURE 14. VM resource overhead using CloudSafe.

V. CONCLUSION
Evaluating the security of the cloud can be a challenging
task due to the scalability and dynamic nature, as well as
the different privilege boundaries between the stakeholders
(e.g., cloud service providers and clients). To address
these problems, we proposed a framework to evaluate the
security of the cloud using CloudSafe. CloudSafe provides
semi-automated functions to collect and store the security
information from the cloud, and also provide functions
to modify the cloud configurations and compare how the
security posture changes in the cloud. The results show that
without too much user interventions, CloudSafe can collect
security data from the cloud, evaluate the security posture
of the cloud using the HARM, and generate reports that
the user can utilize to assess the security of the cloud.
Further, different countermeasures can be pre-evaluated prior
to their deployment using CloudSafe to compare changes in
the security posture of the cloud. However, in this paper,
we experimented with an arbitrarily constructed cloud model.
It needs to be applied to an actual cloud computing system.
Therefore, we plan to expand it so that it can be applied REFERENCES
not only to AWS but also to various clouds such as Azure. [1] P. Mell and T. Grance, The Nist Definition of Cloud Computing, vol. 800.
Gaithersburg, MD, USA: NIST Special, 2011, p. 145.
In addition, we plan to study zero-day attack detection using [2] M. Banikazemi, D. Olshefski, A. Shaikh, J. Tracey, and G. Wang,
anomaly detection. ‘‘Meridian: An SDN platform for cloud network services,’’ IEEE Commun.
Mag., vol. 51, no. 2, pp. 120–127, Feb. 2013.
[3] J. B. Hong, A. Nhlabatsi, D. S. Kim, A. Hussein, N. Fetais, and K. M. Khan,
APPENDIX ‘‘Systematic identification of threats in the cloud: A survey,’’ Comput.
Table 5 shows the AWS resources and service versions used Netw., vol. 150, pp. 46–69, Feb. 2019.
[4] D. Gonzales, J. M. Kaplan, E. Saltzman, Z. Winkelman, and D. Woods,
to set up the testbeds. Each instance had one vCPU and 1GiB ‘‘Cloud-trust—A security assessment model for infrastructure as a service
of memory. Table 6 shows the AWS resources used by the (IaaS) clouds,’’ IEEE Trans. Cloud Comput., vol. 5, no. 3, pp. 523–536,
CloudSafe tool (WS refers to Windows Server). The type of Jul. 2015.
[5] B. Kordy, L. Piètre-Cambacédès, and P. Schweitzer, ‘‘DAG-based attack
those instances was all t2.micro. Table 7 shows the scanned and defense modeling: Don’t miss the forest for the attack trees,’’ Comput.
vulnerabilities in each AMI from the target cloud. Sci. Rev., vol. 13, pp. 1–38, Nov. 2014.

VOLUME 10, 2022 75133

 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

[6] J. B. Hong, D. S. Kim, C.-J. Chung, and D. Huang, ‘‘A survey on the [18] H. H. Song, ‘‘Testing and evaluation system for cloud
usability and practical applications of graphical security models,’’ Comput. computing information security products,’’ Proc. Comput. Sci.,
Sci. Rev., vol. 26, pp. 1–16, Nov. 2017. vol. 166, pp. 84–87, Jan. 2020. [Online]. Available: https://www.
[7] M. Chu, K. Ingols, R. Lippmann, S. Webster, and S. Boyer, ‘‘Visualizing sciencedirect.com/science/article/pii/S1877050920301459
attack graphs, reachability, and trust relationships with NAVIGATOR,’’ in [19] S. Preda, F. Cuppens, N. Cuppens-Boulahia, J. Garcia-Alfaro, and
Proc. 7th Int. Symp. Vis. Cyber Secur. (VizSec), 2010, pp. 22–33. L. Toutain, ‘‘Dynamic deployment of context-aware access control
[8] X. Ou, S. Govindavajhala, and A. W. Appel, ‘‘MulVAL: A logic-based policies for constrained security devices,’’ J. Syst. Softw., vol. 84, no. 7,
network security analyzer,’’ in Proc. USENIX Secur. Symp., Baltimore, pp. 1144–1159, Jul. 2011.
MD, USA, vol. 8, 2005, pp. 113–128. [20] H. Kawashiro and M. Asano. (Jan. 2012). Web Vulnerability
[9] C. J. Chung, P. Khatkar, T. Xing, J. Lee, and D. Huang, ‘‘NICE: Patching Device, Web Server, Web Vulnerability Patching Method,
Network intrusion detection and countermeasure selection in virtual and Programming. [Online]. Available: https://worldwide.espacenet.
network systems,’’ IEEE Trans. Dependable Secure Comput., vol. 10, com/publicationDetails/biblio?FT=D&date=20120126&DB=EPODOC&
no. 4, pp. 198–211, Jul. 2013. locale=&CC=WO&NR=2012011270A1
[10] J. Beale, R. Deraison, H. Meer, R. Temmingh, and C. Walt. (2002). [21] A. Shameli-Sendi, H. Louafi, W. He, and M. Cheriet, ‘‘Dynamic
The Nessus Project. Syn-Gress Publishing. [Online]. Available: optimal countermeasure selection for intrusion response system,’’ IEEE
http://www.nessus.org Trans. Dependable Secure Comput., vol. 15, no. 5, pp. 755–770,
[11] N. I. of Standards and Technology. The National Vulnerability Database. Sep. 2018.
[Online]. Available: https://nvd.nist.gov/ [22] R. Patil and C. Modi, ‘‘Designing an efficient framework for vulnerability
[12] J. B. Hong and D. S. Kim, ‘‘Towards scalable security analysis using multi- assessment and patching (VAP) in virtual environment of cloud comput-
layered security models,’’ J. Netw. Comput. Appl., vol. 75, pp. 156–168, ing,’’ J. Supercomput., vol. 75, no. 5, pp. 2862–2889, Nov. 2018.
Nov. 2016. [23] K. Kritikos, K. Magoutis, M. Papoutsakis, and S. Ioannidis, ‘‘A survey on
[13] S. An, T. Eom, J. S. Park, J. B. Hong, A. Nhlabatsi, N. Fetais, K. M. Khan, vulnerability assessment tools and databases for cloud-based web applica-
and D. S. Kim, ‘‘CloudSafe: A tool for an automated security analysis tions,’’ Array, vols. 3-4, Sep. 2019, Art. no. 100011. [Online]. Available:
for cloud computing,’’ in Proc. 18th IEEE Int. Conf. Trust, Secur. https://www.sciencedirect.com/science/article/pii/S2590005619300116
Privacy Comput. Commun., 13th IEEE Int. Conf. Big Data Sci. Eng. [24] R. Patil and C. Modi, ‘‘An exhaustive survey on security concerns and
(TrustCom/BigDataSE), Oct. 2019, pp. 602–609. solutions at different components of virtualization,’’ ACM Comput. Surv.,
[14] S. Bleikertz, M. Schunter, C. W. Probst, D. Pendarakis, and K. Eriksson, vol. 52, no. 1, pp. 1–38, Feb. 2019, doi: 10.1145/3287306.
‘‘Security audits of multi-tier virtual infrastructures in public infrastructure [25] S. Ullman, S. Samtani, B. Lazarine, H. Zhu, B. Ampel, M. Patton, and
clouds,’’ in Proc. ACM Workshop Cloud Comput. Secur. Workshop H. Chen, ‘‘Smart vulnerability assessment for scientific cyberinfrastruc-
(CCSW), 2010, pp. 93–102. ture: An unsupervised graph embedding approach,’’ in Proc. IEEE Int.
[15] S. Noel, E. Harley, K. H. Tam, M. Limiero, and M. Share, ‘‘CyGraph: Conf. Intell. Secur. Informat. (ISI), Nov. 2020, pp. 1–6.
Graph-based analytics and visualization for cybersecurity,’’ in Handbook [26] S. Jajodia, A. K. Ghosh, V. Subrahmanian, V. Swarup, C. Wang, and
of Statistics, vol. 35. Amsterdam, The Netherlands: Elsevier, 2016, X. S. Wang, Moving Target Defense II Application of Game Theory
pp. 117–167. and Adversarial Modeling (Advances in Information Security), 1st ed.,
[16] S. Rizvi, J. Ryoo, J. Kissell, W. Aiken, and Y. Liu, ‘‘A security evaluation S. Jajodia, A. K. Ghosh, V. S. Subrahmanian, V. Swarup, C. Wang, and
framework for cloud security auditing,’’ J. Supercomput., vol. 74, no. 11, X. S. Wang, Eds. New York, NY, USA: Springer, 2013.
pp. 5774–5796, Nov. 2018. [27] J. B. Hong, D. S. Kim, and A. Haqiq, ‘‘What vulnerability do we need to
[17] S. Manzoor, H. Zhang, and N. Suri, ‘‘Threat modeling and analysis for the patch first?’’ in Proc. 44th Annu. IEEE/IFIP Int. Conf. Dependable Syst.
cloud ecosystem,’’ in Proc. IEEE Int. Conf. Cloud Eng. (ICE), Apr. 2018, Netw., Jun. 2014, pp. 684–689.
pp. 278–281.

75134 VOLUME 10, 2022