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
Cloud computing provides many beneficial factors over the
data and evaluate various attack scenarios of the network,
traditional networks, which enhance the productivity and
as well as the capabilities to incorporate countermeasure
performance of enterprises and individuals [1], [2]. But at
selections. However, automating the functionalities of those
the same time, it faces many security challenges and
models in the cloud can be challenging, as the privilege
threats, affecting the decisions of using cloud computing
boundaries are more complex than the traditional networks.
services significantly [3]. That is, potential cloud users need
Currently, much of the security analysis for the cloud is
to consider various security implications before migrating
done manually by a security expert due to the complexity of
their data and operations to the cloud computing
enabling automation. In the manual process, however, a lot
environment [4]. Although there are various security
of time is consumed and it can also introduce human errors.
mechanisms imple- mented for the cloud, their
Hence, automation is essential to reduce cost and time, as
effectiveness must be evaluated to fully understand the
well as reducing human errors. There are many tools
security posture of the cloud. One of the widely used
available for assessing the security of networks [6]. For
techniques is to develop a security assess- ment framework
example, NAVIGATOR [7], MulVAL [8], and NICE [9] all
using graphical security models [5], [6].
have functions to automatically assess the security of
The associate editor coordinating the review of this manuscript and networks. However, these tools require specific security
approving it for publication was Ali Kashif Bashir . details of 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 graph. Noel et al. [15] proposed a scalable
tools, such as NESSUS [10] and National Vulnerability modeling frame- work to create a predictive model for
Database (NVD) [11], are easily deployed in traditional possible multi-step
networks as typically the whole network is under the
system administrator’s control. However, the cloud
separates the privilege between different stakeholders (e.g.,
clients and service providers), limiting the access to security
information that existing information gathering tools can
access to. Hence, additional measures are needed to ensure
that all this information can be collected automatically to
evaluate the security of the cloud.
To address the aforementioned problems, our main
motiva- tion is to propose an automated cloud-based
security analysis framework named CloudSafe to evaluate
the security of the cloud. In cloud computing, access to
security information by existing security information
collection tools is limited. For that reason, we developed a
framework that can automatically collect information about
cloud computing and perform security assessments. We
present additional techniques to collect security information
from the cloud, which is then stored in a database. For
example, we used Security Group (SG), which is basic
security method of AWS, to collect reachability. As the
security assessment framework in the CloudSafe, we
implement a scalable graphical security model named
Hierarchical Attack Representation Model (HARM) [12].
We further modify the functionalities of the HARM such
that it will integrate with the security data gathering
interfaces we implemented for the CloudSafe. Our prior
work was published in [13], but we have substantially
extended the previous work as follows:
• We incorporated more security countermeasure
approaches into our framework and evaluated their
effectiveness;
• We proposed optimal security countermeasure deploy-
ment strategy in the cloud with multiple
countermeasure selection options (i.e., multi variable
optimization);
• We proposed a novel framework CloudSafe that
extends its features to deploy optimal security
countermeasures in the cloud; and
• We experimented various security countermeasure
selection scenarios in real-world cloud based on AWS.
The rest of the paper is structured as follows. Section II
describes the related work on security assessment for the
cloud. Section III presents the CloudSafe framework with
details on its architecture, configurations and workflow.
Section IV shows the results of using the CloudSafe in the
Amazon AWS. Finally, we conclude the paper in Section
V.

II. RELATED WORK

A. SECURITY ASSESSMENT OF THE CLOUD
Bleikertz et al. [14] proposed a query and policy language
that could be used to specify desired and unwanted config-
urations in the network. When an attack query is entered,
it indicates whether an attack route exists based on the
9582 VOLUME 10, 2022
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

attack paths by combining vulnerability, server configuration,

policy rules, and security events. The generated attack path is
stored in the Neo4j-based database and provides the result of
combining with the input query. Rizvi et al. [16] proposed a
framework for evaluating the security of the cloud. They
presented security evaluation rules to assess the security using
the developed security metrics (based on linear and nonlinear
equations and fuzzy logic systems). However, they only
covered specific aspects of security, such as interoperability,
co-location, transparency, malicious insider and portability.
Manzoor et al. [17] proposed a new security assessment model
for the cloud using Petri Nets. They profile the operational
behaviour of the services in the cloud operations, which are
then used to evaluate the security of the cloud operations in
different layers. However, using Petri Nets can have a
scalability problem, especially for the cloud where
configurations can dynamically change within a short period of
time. There are many other graphical security models that
could be used to assess the security of the cloud [5], [6], [18].
However, we must first specify how the security assessment
could be carried out in the cloud environment ensuring the data
collection, processing and evaluation, which has not been
specified.

B. AUTOMATE DEPLOYMENT OF SECURITY

COUNTERMEASURES IN THE CLOUD
Preda et al. [19] proposed an improved OrBAC
(Organisation-Based Access Control) model to allow for
dynamic deployment of context-aware access control policies
for security devices. Their model allows security officers to
dynamically deploy contextual OrBAC policies (essentially
network traffic policies) over PEPs (Policy Enforcement Points
e.g. routers, firewalls, intrusion detection systems) once
specific contexts become active. Their work provides insight
into methods for dynamically deploying security
countermeasures in the form of OrBAC policies in response to
contextual and environmental system information [19].
However, this is done in traditional networks where control
over lower levels of network architecture is available. As
such this project proposes to find a method for deploying
security countermeasures in the cloud, where underlying
infrastructure is abstracted and granular control over physical
networking devices is unavailable.
Kawashiro and Asano [20] patented a web server vulnera-
bility patching method. Their program detects vulnerabilities
of a web application server, acquiring vulnerability and
appropriate countermeasure information for patching, then
applying vulnerability patching directly to the web appli-
cation. The patent describes the automation of the system
involving a web vulnerability patching device, method and
program [20]. Their work is comparable to CloudSafe in terms
of automated data collection, storage, and assessment, and their
methodology for deploying vulnerability patching to a web
server is significant to the project. However, their work
focussed on web application vulnerabilities on a traditional
network. This must be transferred into the cloud, and for

VOLUME 10, 2022 9583

 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, countermea- sures exist. However, most work focuses
non- patchable vulnerabilities are not addressed in this on evaluating their effectiveness and optimizing for
paper. greatest security benefit.
Shameli-Sendi et al. [21] proposed a dynamic framework
for optimal countermeasure selection for intrusion response
systems. The framework uses a multi-objective
optimization concept to maximize security benefit, while
minimizing the impact on users, services and deployment
costs. The frame- work builds on top of Intrusion Detection
Systems (IDS) that detect exploits in a network, as a
Intrusion Response Sys- tem (IRS) that protects a
compromised network by selecting appropriate security
countermeasures. From this perspective, CloudSafe is a
Intrusion Prevention System (IPS) that actively assesses the
security posture of the network and selects security
countermeasures to protect it. Firstly, in terms of this project,
their work confirms that vulnerability patching and network
traffic management (essentially host isolation) are the most
effective security countermeasures in terms of maximizing
security benefit while minimizing impact on users
deployment costs. Secondly, much of the paper focuses on
the multi-objective optimization problem to select the most
optimal countermeasure which is out of scope of this
project proposal, but can assist in improving CloudSafe in
the future.
Patil and Modi [22] designed a framework for
vulnerability assessment and patching in cloud computing
environments. Their work is very relevant to this project
proposal with much of the assessment framework being
comparable to CloudSafe’s framework. However there are
two issues with the paper. Firstly, it is assumed that the new
joining of VMs is the only source of introducing
vulnerabilities which is inaccurate. Secondly, it is
acknowledged that non-patchable vulnerabilities are not
mitigated, as vulnerability patching is the only security
countermeasure employed. They deal with this problem by
simply marking unpatched VMs as high risk and
continuously monitoring them. However CloudSafe aims to
provide countermeasures for both patchable vulnerabilities
and non-patchable vulnerabilities to minimize risk.
A significant amount of literature on security
9584 VOLUME 10, 2022
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

Although some work covers dynamic security countermea-

sure deployment in the cloud, differences exist as this project
proposes to build on the original CloudSafe tool. A key
difference is security countermeasure deployment integration
with automated security assessment processes.

III. CLOUDSAFE
The details of CloudSafe tool is presented in this section.
CloudSafe follows the SaaS (Software-as-a-Service) frame-
work that can perform cloud security analysis (i.e. a cloud
service for cloud security). Figure 1 shows the overall process
of the CloudSafe framework. The proposed framework is
implemented in the Amazon AWS (AWS for short), and it
consists of two phases. Phase 1 collects information about the
target cloud and stores the data used for the security analysis in
a database. Then, the security is evaluated using the HARM
(Hierarchical Attack Representation Model). HARM is a
security assessment model that can evaluate the security
posture of systems and networks against targeted attacks and
denial of service attacks. Phase 2 generates and stores a new
HARM model by modifying the security information collected
in Phase 1. In this way it can be seen if the security posture of
the cloud changes without changing the actual cloud
configurations.

A. PHASE 1
Reachability of the cloud components in the security analysis
is essential information (e.g., the reachability of different
virtual machines (VMs)). There are various tools for this
purpose, but it is difficult to apply them in the cloud, because
the assessment tool may not have enough privileges to access
such information. To solve this problem, we obtained
Reachability using Security Group (SG), which is the basic
security method of AWS. The SG controls access using IP and
Port as packet filtering. The SG information is used to generate
the Reachability Graph (RG) by considering only the allowed
rules for inbound traffics. Figure 2 shows the process of
acquiring the reachability information from the target cloud
(i.e., the cloud environment to conduct security assessment)
and storing it in the Network Database (NDB)

VOLUME 10, 2022 9585

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

The inputs required to initiate the scan include a

config- uration file that identifies the IP of the machine
running the

FIGURE 2. Reachability scanning in phase 1.

and Host Database (HDB) by parsing the SG to understand

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

VOLUME 10, 2022 9587

 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 /e 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 /e V then
Insert V to VDB
end
if end
for
FIGURE 4. Vulnerability scanning in phase 1. Insert Host to HDB
end procedure

Figure 6 represents the entire DB schema. The

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

cost value as appropriate.

VOLUME 10, 2022 9589

 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
end procedure changes 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
to adapt to changing requirements and demands such as
In order to improve the security of the cloud, we can deploy
increases in network traffic. This introduces the dynamic
security solutions based on the security assessment of the
nature of the cloud, in which virtual machines consistently
cloud we generated from Phase 1. However, it takes many
start and terminate on-demand. As a result, the security
resources to perform these tasks. Consequently, the service
attack surface and thus security posture of a target cloud
can also be stopped in the process. To solve this problem
regularly changes over time. In terms of security, security
and test the security of the cloud, we propose Phase 2 that
assessment methods need to take into account the temporal
can create a new security model of the cloud by modifying
and diverse nature of cloud attack surfaces. Furthermore,
the HARM configuration that was previously stored in the
security countermeasures and their behaviour in the cloud
DB and evaluate their effectivenesses.
need to be considered.
Figure 7 shows the whole process of Phase 2. In this
phase, NDB, HDB, and VDB are modified and saved in the
B.COUNTERMEASURE TYPES
DB. As a result, a new HARM model is generated, and the
security analysis result of the new HARM model is Security countermeasures are a highly researched field,
provided to the user with a comparison report with the with a wide variety of solutions documented for all types
original HARM model generated in Phase 1. Phase 2 works of vulnerabilities. A security countermeasure is generally
recursively to change the cloud configurations in a direction deployed to mitigate the risk from a single vulnerability.
that gradually
9590 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
• Non-Patchable vulnerabilities
5) Run CloudSafe to assess security posture of new
Patchable vulnerabilities are those that have available cloud environment
fixes/patches. These fixes are usually software updates, 6) Analyse effectiveness of security countermeasure by
operating system upgrades, software configuration changes comparing security posture using the following
and security bug fixes. Non-patchable vulnerabilities are criteria:
• Attack Probability (OR & MAX)
those that have no known available fixes, and thus
• Security Risk
mitigation actions need to be taken.
– Sum Risk
Taking into account the impacts of the cloud mentioned
– Max Risk
prior, the security countermeasures that can be deployed • Attack Path Lengths
into the cloud are: 7) Repeat the previous steps iterating through each
• Network Level Security Controls
security countermeasure option
• Host Level Security Controls
Network level security controls involve changes in the net-
D.TESTBED
working abstraction of the cloud. For example,
Below is a list of cloud testbed architectures I initially
manipulating the network topology using security groups in
proposed to analyse security countermeasures on with
AWS to increase the complexity of attack paths to
CloudSafe:
vulnerable hosts. These security controls have no impact at • 3-Tier Web Application (Web Server, Web Applica-
the host level, and therefore usually do not resolve a tion, Database)
vulnerability, but rather reduce risk. Host level security • Streaming Service (FTP, Streamer, Vod Bucket)
controls involve directly applying a patch to a vulnerable
• Web Application with Bastion Host
host. These include changes at the operating system or • Content Distribution Network (CDN)
application level of a host. Host levels security controls Each cloud application architecture has different impli-
generally resolve a risk completely within the system, while cations on the security posture of the cloud. Different
network level security controls mitigate risk to an architectures will have different vulnerabilities, attack paths
acceptable level. Thus host level security controls are and attack surfaces. Due to project schedule constraints and
usually favored when choosing between security the prioritization of security countermeasure deployment,
countermeasures. However, they often require downtime to the 3-tier Web Application architecture was used for the
a service which may result in high costs or is unacceptable entirety of the project due to its simplicity. Theoretically,
in some cases. The consideration of costs to deploying the deployment of a security countermeasure for the same
security 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
C.COUNTERMEASURE ANALYSIS APPROACH
single testbed is reasonable and acceptable for the purposes
Analysis of security countermeasures will occur by identi- of this project. The use of multiple architectures would only
fying the result, requirements, methods, and difficulties of offer the ability to perform different vulnerability patching
deployment. This enables the feasibility of implementing a methods.
solution to deploy the security countermeasure to the cloud. The testbed will be used to analyse the effectiveness
The effectiveness of a security countermeasure will be ini- of security countermeasures. Figure 8 displays how the 3-
tially tested by manually implementing the countermeasure Tier web application architecture will be set up in AWS.
into a cloud testbed for this project when possible, An internet gateway will provide the subnet access to the
otherwise the theoretical outcome will be used. internet; however, each security group will control inbound
The security countermeasures that will be evaluated are: network traffic with granular control. The use of three
• Vulnerability Patching
security groups in AWS is equivalent to having 3 subnets
• Virtual Patching
on a LAN from a networking perspective:
• Network Hardening
• Web SG - will allow http and https (port 80 and 443)
• Moving Target Defence
communication with the internet
These are generalised security controls applicable to almost
• App SG - will allow traffic from the Web SG on port
any cloud environment that uses the cloud provider’s main
8080 (application specific)
compute offering and networking abstraction. In this case,
• DB SG - will allow traffic from the App SG on port
EC2 instances for compute workloads and Security Groups
3306 (database port)
for networking.
• All SG - will allow ssh (port 22) communication from
Evaluation of security countermeasures will occur
a specific IP address range
through the following steps: As illustrated in figure 8, there will be two instances to
1) Setup AWS testbed
mimic web servers, two instances for application servers,
2) Run CloudSafe phase 1 on testbed and determine
and a single database instance (An instance is a virtual
initial security posture
machine within AWS). These instances will each be running
VOLUME 10, 2022 9591
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

purposely vulnerable containers (software), so that appropriate

security

9592 VOLUME 10, 2022

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

security groups that

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
are named ’cloudsafe-a-db-metasploitable2’. Additionally,
the figure shows the instance running OpenVAS, and
another running MongoDB used by CloudSafe for
vulnerability and host data storage. Figure 10 illustrates the
VOLUME 10, 2022 9593
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing
TABLE 1. NMap scan results.

FIGURE 10. AWS CloudSafe security groups.

were configured for the testbed initially and their relationship

between each other. The specific network traffic ingress rules

9594 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 3306 for
testing.
Table 5(a) displays the raw results of running the auto-
mated scanning program on the initial testbed environment
within AWS. These results are used as a benchmark
for evaluating security countermeasure effectiveness later.
As determined from the program, the accumulative risk for
the initial testbed is 268.53, with a total of 28
vulnerabilities within the whole system. The accumulative
risk is calculated from all vulnerabilities found on all hosts.
As such, the risk value from a specific vulnerability present
on multiple hosts will be higher in the end. This is
reasonable as a vulnerability found throughout an entire
system is arguably higher risk than a vulnerability only on a
specific host, as the likelihood of vulnerability exploitation
is multiplied. For simplification purposes, attack surface
and attack path calculation are not conducted within this
project. From the host summary, the host type can be
identified from the vulnerable ports. The database instance
has port 3306 exposed, the application instance has port
9200 exposed, and web server instances have all ports
exposed by the security group ingress rules.

E.VULNERABILITY PATCHING
Vulnerability patching is the action of applying patches or
fixes to vulnerable hosts or their affected software. There
are numerous types of patching that can be applied to hosts
as it is a relatively general term. Examples include updating
software, changing operating system versions, installing
security bug fixes, or changing software configuration.
Vulnerability patching is a host level security control that
addresses the vulnerability directly.
The security control generally resolves a vulnerability
completely and mitigates its risk from all affected hosts.
If applied, the countermeasure can reduce the possible
attack paths within the network by blocking attackers from
hosts deeper within the network. As a result, the overall
security posture should improve significantly after
implementing vulnerability patching. On the other hand,
patching directly on hosts may result in service downtime
which may lead to further costs. Downtime can be avoided
depending on the deployment method, however.
Additionally, a singular patch may only be valid for a
specific vulnerability on specific software versions,
operating systems, and further dependencies.

F.VIRTUAL PATCHING
Virtual patching is the action of virtually applying a patch
to a vulnerability on a host directly. Various methods may
be implemented to achieve virtual patching, however, they
should have the same effect on the host. Virtual patching
leaves alone the affected software and manipulates the host
in such a way that the vulnerable software is unreachable.
Virtual patching is a host level security control that
addresses the vulnerability directly.
An example includes disabling the port on a host
associated with a vulnerable software (e.g., closing port
VOLUME 10, 2022 9595
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

a instance running vulnerable database software). As a result,

although the vulnerable software is still running, the
vulnerability cannot be reached thus blocking an attacker.
Subsequently, virtual patching will also block legitimate users
or dependent software from reaching the service, ren- dering
the port/service unusable. Virtual patching is however useful
for newly discovered non-patchable vulnerabilities as a good
short-term solution until a patch becomes available.

G.NETWORK HARDENING
Network hardening is the process of locking down exposed
ports within the networking abstraction of the cloud. As such it
is very similar to virtual patching in terms of its behaviour of
allowing vulnerable software to exist, but denying access to it.
Network hardening is usually a method for ensuring best
security practices within cloud environments, but can also be
deployed as a countermeasure to a newly discovered
vulnerability. Network Hardening is a network level security
control that manipulates the networking within the cloud and
does not affect hosts directly. In AWS, this include Network
Access Control List (NACL) manipulations, and Security
Group (SG) manipulations. NACLs and SGs have essentially
the same behavior, however, the implications to networking
between hosts are different. For the purposes of the project,
Security Groups will be focussed on. Similarly to virtual
patching, host hardening can mitigate risk completely and is a
good short-term solution until a vendor fix is available.
Using security groups, which provide granular control over
ingress traffic to instances, a system administrator can lock
down access to certain ports to certain IP address ranges using
CIDR blocks. By doing this, services can be accessed only
from trusted IP ranges, significantly reducing the risk of
attackers being able to exploit any vulnerabilities. Assessing
the security posture of the environment after doing so is more
difficult as attackers may use IP spoofing or other techniques
to overcome this.

H. MOVING TARGET DEFENCE

Moving Target Defence (MTD) is a relatively novel security
countermeasure with less literature available than other
security controls. MTD involves changing aspects of the
system to present attackers with a varying attack surface,
making it much more difficult for an attack to exploit a
vulnerable system. The hope is that in the time it takes for an
attacker to learn the properties and construct the exploit, the
system would have changed enough by the time the attacker
can launch the exploit [26]. The effectiveness of MTD has
been debated heavily, however, MTD is generally more
effective in complex systems, with its effectiveness
diminishing heavily within simpler systems.
The implementation of MTD can provide an extra layer of
security to a cloud environment alongside additional security
controls. However MTD requires a large amount of overhead
in implementation that is heavily dependent on system
implementation. MTD is especially useful against

9596 VOLUME 10, 2022

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

Advanced Persistent Threats (APTs) that require time and example, Ansible can automatically
planning to coordinate and launch [26].

2) SECURITY COUNTERMEASURE DEPLOYMENTS

The proposed Phase 3 of CloudSafe, involves the
deployment of security countermeasures to the cloud in an
automated programmatic fashion. Phase 3 should integrate
with the rest of the CloudSafe Framework and should take
the output from phases 1 and 2 as input into the security
countermeasures.
As an initial proposal regarding the framework, the steps
for phase 3 include:
1) Identify security countermeasure options according to
vulnerabilities discovered
2) Determine optimal security countermeasure deploy-
ment order
3) Deploy security countermeasure to target cloud
Step 1 takes into account the output from the CloudSafe
Program in addition to the OpenVAS vulnerability report to
determine the possible security countermeasure options. Step
2 relates to optimal security countermeasure selection and
ordering from the set of possible options. This step involves
solving a multi-objective security hardening optimization
problem. This is out of scope for the project. Step 3 is the
primary focus for this report. The security countermeasure
option analysis conducted within this project provides an
initial foundation for possible security countermeasures and
their feasibility. This section details the countermeasure
deployment implementations for each option deemed
feasible within the scope of the project from the analysis.
The countermeasure options implemented as a result of the
analysis include:
• Virtual Patching
• Network Hardening
• Moving Target Defence
Assumption: For any system, the deployment of security
countermeasures requires administrator access to the cloud
resources. Therefore agent-based software and the instal-
lation of tools into the administrator’s cloud for security
countermeasure deployment is within scope of the project.
Below is a list of proposed tools and software that were
taken into consideration to implement the deployment of
security countermeasures or be used in the project:
• Python - Python is an interpreted, high-level, general-
purpose programming language. Python is widely
popular and used for many purposes. For this project,
python is the programming language of choice for
implementing scripts due it its readability and
simplicity. For a deployment workload, performance
and speed is not an issue, as such a general-purpose
programming language is well within reason.
• Ansible - Ansible is an open-source software
provision- ing, configuration management, and
orchestration tool. Using Ansible, administrators can
effectively manage entire networks, application life
cycles, and cloud envi- ronments, from simple
provisioning tasks to complex workflows. For
VOLUME 10, 2022 9597
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

perform a rolling update on all machines in a system to

their latest versions. For this project, Ansible would be
able to perform vulnerability patching on affected
machines or be able to apply security group changes to
AWS. Additionally, Ansible is agentless meaning
minimal setup is required allowing for simplicity of use.
• Jenkins - Jenkins is an open-source automation server. It
is a popular software enabling DevOps practices with
CI/CD (Continuous Integration & Continuous Delivery).
Jenkins could be used in this project to integrate DevOps
practices and allow for continuous delivery of security
countermeasures to the cloud. The use of Jenkins requires
the deployment of a Jenkins server potentially on an EC2
instance. Due to this overhead in implementation the
potential for use of Jenkins is lowered.
• Packer - Packer is an open-source tool that automates the
creation of any type of machine image. Packer uses
automated scripts to install and configure software within
Packer-made images. Packer can easily be used to apply
vulnerability patches to AMIs, however another tool will
be required to deploy the resulting images such as AWS
CLI or Ansible. For this project, Packer can be used to
generate images used for the testbeds to ensure
consistency.
• Containers (Kubernetes & Docker) - Containers are
packages that include a software’s code and all its
dependencies, that can be run quickly and reliable in any
computing environment. Docker is a container run- time
engine, and Kubernetes is a container orchestration
platform. The use of containers would simplify the
process of creating and running images. Containers could
be used to simplify the setup of testbeds for evaluation
security countermeasure effectiveness.
• AWS CloudFormation - CloudFormation is an AWS
service for provisioning and managing AWS resources as
code (Infrastructure-As-Code). It provides a way to model
your applications or cloud environments into re-usable
and version-controlled templates. The use of
CloudFormation would provide a simple method to
implement AMI updates and security group changes,
however, would require CloudFormation as to be part of
the underlying infrastructure. CloudFormation could be
used to simplify the set up and management of the testbed.

A.VIRTUAL PATCHING
To deploy virtual patching, an ansible script was created to
programmatically disable a vulnerable port on all specified
hosts automatically. The ansible script has the following
requirements:
• Anisble
• Python
• SSH access to targets - Private Key
• AWS API Permissions
• AWS SDK (boto3)

9598 VOLUME 10, 2022

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

The inputs to the ansible script include: created to programmatically change the public IPs of
• Port to disable each
• Security Group of instances to apply virtual patching
to The simplified steps of the ansible script are as follows:
1) Parse inputs
2) Using AWS API calls -> determine all instances
and their IPs within the security groups inputted
3) SSH into each instance using private key defined in
ansible configuration
4) Using iptables module -> create rule to drop
packets
incoming from inputted port on each instance
The ansible script can be initiated using the command
line with a single simple command. This implementation
is a proof of concept that programmatically applies virtual
patching to a set of hosts. Although the inputs are provided
manually by a local configuration file, they can be inputted
programmatically and integrated with output from phase
1. Additionally, the method of defining which hosts to
apply virtual patching to can be modified to provide better
flexibility for the security countermeasure option.

B.NETWORK HARDENING
To deploy networking hardening a python program was
created to programmatically manipulate Security Groups to
lock down vulnerable ports and deny access. Due to the
difficulties on implementing a security group manipulation
solution stated in the analysis prior, this implementation is a
proof of concept only and requires further development.
The python program requirements include:
• Python
• AWS SDK
• AWS API permissions
The inputs to the python program are:
• Host summary output from automated scanning
program The steps of the python program are as follows:
• From the host summary -> Parse each host’s
vulnerable ports
• Using AWS API -> Retrieve all ingress rules within
each instance’s security groups
• Map each host’s vulnerable port to any and all ingress
rules they match and are associated with
• Iterate through all ingress rules have that vulnerable
ports and revoke using AWS API call
A key problem met when developing this solution was the
need to map each host’s vulnerable ports to all ingress rules
they matched and are associated with programmatically.
The issue was that instance may have multiple Security
Groups, and Security Groups may have multiple ingress
rules, that may have port ranges, and rules that overlapped.
The program needed to identify all vulnerable ingress rules
and revoke them. This was solved by individually iterating
through each instance and it’s security group ingress rules
and determine any vulnerable ingress rule and storing that
within a mapping.

C.MOVING TARGET DEFENCE

To deploy MTD to the target cloud, a python program was
VOLUME 10, 2022 9599
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

instance defined periodically. Periodically changing the IPs of

all instances within the environment would present a
potentially dynamically changing attack surface for attackers.
Note: The python program is purely a proof of concept for
demonstrating a changing attack surface and is not practical
to deploy.
The use of MTD in this case would require deployment of
an external load balancer to consistently point to the changing
endpoint locations, or the deployment of a service discovery
application to enable consistent communication between
services with dynamic endpoints. The python script takes
advantage of a certain behaviour within AWS, being that when
an elastic IP is attached then disassociated from an instance,
the instance IP will reset to a random IP within the AWS IP
pool. By doing this periodically for each instance, MTD can be
demonstrated.

IV. EXPERIMENTAL ANALYSIS

For the experiment, we set up two different cloud testbeds to
demonstrate the applicability and practical use of the
CloudSafe tool. The two target clouds were implemented in
the AWS. The AWS provides an interface to monitor when
security policies are applied. So we set up the testbeds in the
AWS to check the status of the cloud using that interface. The
first is implemented in three tiers of Web, App, and DB, and
the second one is implemented as a streaming server. The
configuration of the testbeds is detailed in Table 7. We show
how the two phases described in the previous section are
applied in the two cloud testbeds in the following subsections.
For simplicity, two security metrics (attack probability and
security risk) are used to demonstrate the application of
CloudSafe tool. However, other security metrics can be used to
evaluate the security posture as well, as shown in [6].

A. APPLYING PHASE 1 IN THE TESTBEDS

Figure 11 shows the connections between the AMI and SG in
testbed 1. The DB only allows connections from the App, and
the App only uses connections from the Web. The Web allows
connections via HTTP and https. All AMIs allow connection
of a specific IP from port 22, which is for using SSH.
As an illustrative example, Figure 12 shows the HARM
model generated for testbed 1. Potential attack possible paths
are calculated in HARM. Users can also retrieve the graphical
view of the HARM to understand the cloud components and
their security relationships. We omit the illustrative example
for testbed 2 due to the limited space.
Table 2 shows the security analysis results for testbed 1, and
Table 3 for testbed 2. They include the security analysis
results from both Phase 1 and Phase 2, which can be
compared directly. The CloudSafe tool generates the security
report using various security metrics, and other relevant
metrics, not only security related (e.g., performance, reliability
etc), can also be implemented as additional metric modules
and integrated with the HARM. By generating those security
reports, we can easily compare different security aspects of
various cloud environments. One note is that using

9600 VOLUME 10, 2022

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

VOLUME 10, 2022 9601

 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:
A. Replacing the web server Metasploitable 2 instances
with new instance running nginx (web server software).
B.Replacing the application Metasploitable 3 instances
with new instance running application software.
C.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
FIGURE 13. Changes in security posture when patching
vulnerabilities using PSV. (a) and (b) show the risk report for testbed
program again. Consolidating the statements made prior,
1 and testbed 2, respectively. (c) and (d) show the probability of attack the patching successfully removed the vulnerabilities from
success report for testbed 1 and testbed 2, respectively. the database instance and system. The results of the new
scan are displayed in Table IV-B(b). The summated risk
applied to improve the security of a network using the of the new environment was 234.1, a significant decrease
HARM. For our implementations, we use the exhaustive from 268.53 prior to implementing the patch. From the host
search (ES) algorithm method among other PSV summary, the new database host ’10.50.16.28’ running the
algorithms. The ES algorithm uses the risk and cost values latest PostgreSQL version had no vulnerabilities with a 0
to prioritize vulnerabilities to be patched in the cloud risk metric and no vulnerable ports discovered from the
testbeds. Table 6 shows the PSV ranking of the testbeds, scan.
and the result of applying PSV to the testbeds is shown Requirements: Regarding implementing vulnerability
in Figure 13. We eliminated the vulnerability sequentially patching as a security countermeasure, the requirements and
from ES1 to ES5 respectively, and the results show the dependencies are as follows:
gradual reduction in the risk and the probability of attack • Ability to perform patching on machines either directly,
success. or on a separate security environment.
9602 VOLUME 10, 2022
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

• A patch is available - only for patchable vulnerabilities

VOLUME 10, 2022 9603

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

mentations

VOLUME 10, 2022 9605

 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,
The implementation will be a proof of concept that will
network- ing hardening also theoretically mitigates risk
have assumptions regarding the cloud environment and the
from locked down ports completely, while also
application.
consequently deny all access to any services behind the port.
To test to effectiveness

9606 VOLUME 10, 2022

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

of network hardening the security group of the web server is out of scope.
instances will be locked down to only expose ports 22, 80
and 443 (standard web server ports). Looking at the host
summary of the initial testbed environment, the web server
instances have a several vulnerable ports contributing
significantly to the accumulative risk. Conducting this
network hardening should reduce the sum risk of the
environment greatly. The steps for testing in AWS are as
follows:
1) Access AWS console
2) Navigate to the web server security group
3) Remove the unnecessary ingress traffic rules
4) Add ingress from any IP address for TCP ports 22,
80 and 443
Assessing the security posture of the new cloud
environment provided in Table 5(d) confirms that network
hardening successfully resolves the risk from any locked
down port completely. The results of the security posture
assessment display a accumulative risk of 59.29, a major
reduction from
268.53 initially. Examining the host summary consolidates
the statements made prior, as the web server instances only
have one vulnerable port
Requirements: To implement network hardening as a
security countermeasure for Phase 3, the only requirement
is access to AWS credentials and AWS API permissions.
Methods: As mentioned briefly previously, the two
methods to implementing network hardening in AWS are
though NACL manipulation or SG manipulation. Security
Group manipulation can be performed either manually in
the AWS console, a program using AWS Software
Development Kit (SDK) or through a script using AWS
Command Line Tool (CLI).
Difficulties: The difficulties regarding implementing a
network hardening solution include:
• Systems with complex network topologies will
increase difficulty exponentially
• Required services and their exposed ports need to be
understood
• Security Group rules may be implemented differently
for different applications/systems
• Vulnerable ports may be allowed by multiple ingress
rules in multiple security groups
• Ingress rules may contain port ranges - changes need
to preserve those ranges
Feasibility: Although there are several difficulties and
nuances regarding a solution for network hardening, the
design and implementation of a proof of concept using the
AWS SDK is within the scope of the project.

4) MOVING TARGET DEFENCE

Results: As mentioned above, the effectiveness of MTD as
a security countermeasure is difficult to gauge. For the
scope of this project, the testing of MTD on a simple 3-tier
web application architecture is unreasonable. Additionally,
with the CloudSafe framework and simple security metrics
used for this project, determining the effectiveness of MTD
VOLUME 10, 2022 9607
 S. An et al.: Toward Automated Security Analysis and Enforcement for Cloud Computing

Requirements: To implement MTD as a security counter-

measure for Phase 3, the only requirement is access to AWS
credentials and AWS API permissions.
Methods: The diversity in the attack surface can be created
through multiple methods. Alternatives include diversity in
terms of the software and applications within the system, and
diversity through rotational changes in endpoint locations.
Difficulties: The difficulties regarding implementing a MTD
solution as a security countermeasure option for Phase 3
include:
• Systems with complex network topologies
• Dynamicity needs to be a component developed into the
system
• Systems may require static components (e.g. static
endpoints)
• Large overhead in implementation
• Countermeasure effectiveness is difficult to assess
• Security Groups may be implemented differently for
different systems
Feasibility: Despite difficulties regarding MTD, it is feasible
to implement a simple MTD solution as a security
countermeasure option for Phase 3. Considering the scope of
the project and constraints, a simple proof of concept is
implementable.

D. OVERHEAD
To understand the performance overhead using CloudSafe, we
measure the time take in Phase 1. The time taken using the
CloudSafe tool on testbed 1 was measured and the mean value
was used from 10 measurements. Table 4 shows the overhead
of gathering the data to populate the DBs. It shows that most
tasks can be completed reasonably quickly (within a matter of
a few seconds), while the biggest bottleneck is the
vulnerability scanning of VMs. One approach to improve the
vulnerability scanning time is to reduce the port range to scan,
but vulnerabilities outside the measurement range would not
be included in the analysis. Another approach is to parallelize
the vulnerability scanning using the cloud, which we will
investigate in our future work.
Next, we measure the computational overhead using
CloudSafe. The use of the vulnerability analysis tools is
the only factor that affects the VM when using CloudSafe.
Figure 14 shows the load on the CPU and the network of the
VMs when using CloudSafe. All TCP/IP ports were scanned
and the load was measured in 1-minute increments. During the
measurement, CPU usage increased by up to 11 percent, and
the network had a maximum input of 5,042 bytes per minute
and an output of 416 bytes. During the tool usage period, the
cumulative input was 11,163 bytes and the output was 1,234
bytes. Network load was not large, but the CPU utilization
increased significantly. There is a need to adjust the scan
options depending on the host’s CPU performance or the role.
On the other hand, disk reads and writes were almost
unchanged.

9608 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 REFERENCES
computing system. Therefore, we plan to expand it so [1] P. Mell and T. Grance, The Nist Definition of Cloud Computing, vol. 800.
Gaithersburg, MD, USA: NIST Special, 2011, p. 145.
that it can be applied not only to AWS but also to various [2] M. Banikazemi, D. Olshefski, A. Shaikh, J. Tracey, and G. Wang,
clouds such as Azure. In addition, we plan to study zero- ‘‘Meridian: An SDN platform for cloud network services,’’ IEEE Commun.
day attack detection using anomaly detection. 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, ‘‘Systematic identification of threats in the cloud: A survey,’’
Comput. Netw., vol. 150, pp. 46–69, Feb. 2019.
APPENDIX [4] D. Gonzales, J. M. Kaplan, E. Saltzman, Z. Winkelman, and D. Woods,
Table 5 shows the AWS resources and service versions ‘‘Cloud-trust—A security assessment model for infrastructure as a service
used to set up the testbeds. Each instance had one vCPU (IaaS) clouds,’’ IEEE Trans. Cloud Comput., vol. 5, no. 3, pp. 523–536,
Jul. 2015.
and 1GiB of memory. Table 6 shows the AWS resources [5] B. Kordy, L. Piètre-Cambacédès, and P. Schweitzer, ‘‘DAG-based attack
used by the CloudSafe tool (WS refers to Windows Server). and defense modeling: Don’t miss the forest for the attack trees,’’
The type of those instances was all t2.micro. Table 7 shows Comput. Sci. Rev., vol. 13, pp. 1–38, Nov. 2014.
the scanned vulnerabilities in each AMI from the target
cloud.
VOLUME 10, 2022 9609
 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. Sci. Rev., vol. 26, pp. 1–16, Nov. 2017. computing information security products,’’ Proc. Comput. Sci.,
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,’’
[19] S. Preda, F. Cuppens, N. Cuppens-Boulahia, J. Garcia-Alfaro, and
in Proc. 7th Int. Symp. Vis. Cyber Secur. (VizSec), 2010, pp. 22–33.
[8] X. Ou, S. Govindavajhala, and A. W. Appel, ‘‘MulVAL: A logic-based L. Toutain, ‘‘Dynamic deployment of context-aware access control
network security analyzer,’’ in Proc. USENIX Secur. Symp., Baltimore, policies for constrained security devices,’’ J. Syst. Softw., vol. 84, no. 7,
MD, USA, vol. 8, 2005, pp. 113–128. pp. 1144–1159, Jul. 2011.
[9] C. J. Chung, P. Khatkar, T. Xing, J. Lee, and D. Huang, ‘‘NICE: [20] H. Kawashiro and M. Asano. (Jan. 2012). Web Vulnerability
Network intrusion detection and countermeasure selection in virtual Patching Device, Web Server, Web Vulnerability Patching Method,
network systems,’’ IEEE Trans. Dependable Secure Comput., vol. 10, and Programming. [Online]. Available: https://worldwide.espacenet.
no. 4, pp. 198–211, Jul. 2013. com/publicationDetails/biblio?FT=D&date=20120126&DB=EPODOC&
[10] J. Beale, R. Deraison, H. Meer, R. Temmingh, and C. Walt. (2002). locale=&CC=WO&NR=2012011270A1
The Nessus Project. Syn-Gress Publishing. [Online]. Available: [21] A. Shameli-Sendi, H. Louafi, W. He, and M. Cheriet, ‘‘Dynamic
http://www.nessus.org optimal countermeasure selection for intrusion response system,’’ IEEE
[11] N. I. of Standards and Technology. The National Vulnerability Database. Trans. Dependable Secure Comput., vol. 15, no. 5, pp. 755–770,
[Online]. Available: https://nvd.nist.gov/ Sep. 2018.
[12] J. B. Hong and D. S. Kim, ‘‘Towards scalable security analysis using [22] R. Patil and C. Modi, ‘‘Designing an efficient framework for vulnerability
multi- layered security models,’’ J. Netw. Comput. Appl., vol. 75, pp. assessment and patching (VAP) in virtual environment of cloud comput-
156–168, Nov. 2016. ing,’’ J. Supercomput., vol. 75, no. 5, pp. 2862–2889, Nov. 2018.
[13] S. An, T. Eom, J. S. Park, J. B. Hong, A. Nhlabatsi, N. Fetais, K. M. [23] K. Kritikos, K. Magoutis, M. Papoutsakis, and S. Ioannidis, ‘‘A survey on
Khan, and D. S. Kim, ‘‘CloudSafe: A tool for an automated security vulnerability assessment tools and databases for cloud-based web applica-
analysis for cloud computing,’’ in Proc. 18th IEEE Int. Conf. Trust, tions,’’ Array, vols. 3-4, Sep. 2019, Art. no. 100011. [Online]. Available:
Secur. Privacy Comput. Commun., 13th IEEE Int. Conf. Big Data Sci. https://www.sciencedirect.com/science/article/pii/S2590005619300116
Eng. (TrustCom/BigDataSE), Oct. 2019, pp. 602–609. [24] R. Patil and C. Modi, ‘‘An exhaustive survey on security concerns and
[14] S. Bleikertz, M. Schunter, C. W. Probst, D. Pendarakis, and K. Eriksson, solutions at different components of virtualization,’’ ACM Comput. Surv.,
‘‘Security audits of multi-tier virtual infrastructures in public vol. 52, no. 1, pp. 1–38, Feb. 2019, doi: 10.1145/3287306.
infrastructure clouds,’’ in Proc. ACM Workshop Cloud Comput. Secur. [25] S. Ullman, S. Samtani, B. Lazarine, H. Zhu, B. Ampel, M. Patton, and
Workshop (CCSW), 2010, pp. 93–102. H. Chen, ‘‘Smart vulnerability assessment for scientific cyberinfrastruc-
[15] S. Noel, E. Harley, K. H. Tam, M. Limiero, and M. Share, ‘‘CyGraph: ture: An unsupervised graph embedding approach,’’ in Proc. IEEE Int.
Graph-based analytics and visualization for cybersecurity,’’ in Handbook Conf. Intell. Secur. Informat. (ISI), Nov. 2020, pp. 1–6.
of Statistics, vol. 35. Amsterdam, The Netherlands: Elsevier, 2016, [26] S. Jajodia, A. K. Ghosh, V. Subrahmanian, V. Swarup, C. Wang, and
pp. 117–167. X. S. Wang, Moving Target Defense II Application of Game Theory
[16] S. Rizvi, J. Ryoo, J. Kissell, W. Aiken, and Y. Liu, ‘‘A security and Adversarial Modeling (Advances in Information Security), 1st ed.,
evaluation framework for cloud security auditing,’’ J. Supercomput., vol. S. Jajodia, A. K. Ghosh, V. S. Subrahmanian, V. Swarup, C. Wang, and
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 patch first?’’ in Proc. 44th Annu. IEEE/IFIP Int. Conf. Dependable Syst.
the cloud ecosystem,’’ in Proc. IEEE Int. Conf. Cloud Eng. (ICE), Apr. Netw., Jun. 2014, pp. 684–689.
2018,
pp. 278–281.

9610 VOLUME 10, 2022