Journal of Information Security and Applications 54 (2020) 102594

Contents lists available at ScienceDirect

Journal of Information Security and Applications

journal homepage: www.elsevier.com/locate/jisa

A unified framework for cloud security transparency and audit

Umar Mukhtar Ismail a, *, Shareeful Islam b
a
Centre for Secure, Intelligent and Usable Systems, University of Brighton, UK
b
School of Architecture, Computing and Engineering, University of East London, UK

A R T I C L E I N F O A B S T R A C T

Keywords: The paradigm of cloud computing has elevated IT to new heights by offering the elasticity to match customer
Security audit needs, while also reducing capital expenditure on procuring IT infrastructure. Despite the apparent benefits
Cloud security transparency provided by cloud computing, organisations are slow in embracing the technology due to numerous issues that
Cloud audit
are associated with the lack of security transparency such as trust and accountability. Several contributions have
Security requirements
been proposed to address these issues. However, most of the contributions have not provided a definite method
by which security transparency can be achieved based on user requirements, and particularly, by probing or
auditing cloud service providers. In this paper, we propose a framework for addressing a pressing challenge of
cloud security transparency. Our approach includes a process and a supporting auditing tool for vetting cloud
service providers and enabling security transparency based on predefined user requirements. The paper builds on
our previous work on security transparency framework by incorporating an implementation process. In addition,
we have developed a Security Transparency and Audit Tool through which users can collect and analyze evi­
dence from cloud service providers for determining conformity to requirements, as well as for the specification of
remedial actions. The tool is designed to be a supplementary component of the proposed framework that enables
continuous probing and vetting of cloud provider meets user requirements, thereby enhancing security trans­
parency. The work is novel in its approach because it consolidates various elements to provide a simplified
method for organizations to attain security transparency. We also believe that the contributions are significant
towards solving the issues and challenges of cloud security transparency in general.

1. Introduction
The cloud computing (CC) industry has witnessed a healthy expan­
sion in recent years, and research has shown an increase in sales,
adoption and business acceptance of the technology [1]. Yet, the tran­
sition of mission-critical data and workloads to the cloud require user
trust [2]. Security transparency and audit are two essential factors that
must be considered to increase user trust particularly because companies
expanding the use of cloud services have consistently expressed con­
cerns over the commitment of cloud service providers (CSPs) to guar­
antee adequate fulfilment of specific assets requirements [3]. Security
transparency refers to a process by which information about the security
practices and procedures for protecting customer assets are made
available, accessible, and visible to customers, which promotes assur­
ance and accountability. Security auditing, on the other hand, is the
process of tracking and logging of significant events that take place
during system run-time. It helps in the analysis, verification and vali­
dation of security measures to achieve overall security objectives in a
system.
The uncertainty and doubts surrounding CSP services as a result of
lack of security transparency and audit thwart the wide adoption of
cloud services [4–6]. In particular, issues such as compromise of user
security requirements, unavailability of vetting and probing of cloud
services will continue to forestall businesses’ desire to extend cloud
usage. The absence of security audit techniques based on specific needs
and requirements is another aspect of the pressing problems. The
auditing of CSP security practices according to predefined requirements
is essential because businesses rely on critical assets, their protection
and control to complete key business processes.
Several contributions have been proposed in the current state-of-the-
art to address the problem such as industry best practices and standards,
security and accountability audits, SLA management, security incident
management, virtual machine introspection, etc. For example, virtual
machine introspection considers deploying monitoring agents inside
virtual machines and the collection of evidence for determining security
incidents and breaches. However, these approaches have not considered

* Correspoding author.
E-mail addresses: u.ismail@brighton.ac.uk (U.M. Ismail), shareeful@uel.ac.uk (S. Islam).

https://doi.org/10.1016/j.jisa.2020.102594

Available online 20 August 2020

2214-2126/© 2020 Elsevier Ltd. All rights reserved.
U.M. Ismail and S. Islam
the need to collect evidence from other sources and aspects of CSP op­
erations such as disaster recovery and business continuity plans. Also,
other initiatives such as CSA STAR [7] only support organisations to
consider CSP assertions but does not support evidence-based vetting and
probing of CSPs.
Therefore, given the challenges mentioned above, the novelty of this
work is three folds. Firstly, we proposed a unified framework, namely
Security Transparency and Audit Framework (STAF) for ensuring se­
curity transparency using audit. The STAF adopts a multi-tiered
approach and considered essential concepts for security such as trans­
parency (accessibility to information), and audit (assessment of evi­
dence), and integrated these concepts to develop a unified framework.
The framework includes a systematic process which supports assurance
of security transparency through a comprehensive set of activities.
Secondly, we proposed security transparency and audit tool (STAT) that
is designed to support organizations in performing a security audit.
STAT has unique features for enabling the collection and assessment of
evidence regarding CSPs conformance to a predefined set of organisa­
tional requirements, imposing remedial actions to address flaws and for
tracking the implementation of remedial actions. The last contribution is
the evaluation of the proposed framework, which assesses the validity
and acceptability of STAF, its process and STAT to real-world use cases.
Stakeholders feedback and opinion regarding STAF and STAT are
collected and analyzed based on important criterion derived from
technology acceptance model [8], and perceived usefulness, perceived
ease of use and user acceptance of information technology [9]. The
evaluation results produced encouraging findings that manifest the
relevance, validity and acceptability of the proposed STAF among or­
ganizations. Our approach has proven to be simplistic in terms of
implementation and applicable to different contexts. The participants
expressed optimism about the proposed STAF and its potentiality in
addressing the current and emerging security transparency issues in
cloud computing.
The paper is structured as follows: Section 2 discusses the related in
the domain of security transparency and audit in cloud computing.
Section 3 provides the methodology used in our approach. Section 4
introduces the integrated cloud security transparency and audit frame­
work and the conceptual view of STAF. The section also covers the basics
of security transparency in the cloud, including a formal representation
of concepts using an ontology, and a systematic process for imple­
menting the framework. In Section 5, the architecture of STAT,
including its features and dashboards, are presented. In Section 6, the
deployment architecture of the proposed framework that is designed
based on secure multi-agent systems (MAS). It shows the secure inter­
action between CSPs, CSUs and the role of an independent auditor.
Section 7 introduces the validation approach of our work using a case
study, including the implementation process of activities in the frame­
work and assessment of stakeholder perception. Section 8 provides the
general findings, limitations and comparison of our works to existing
works, and a summary of future works. Finally, Section 9 concludes the
paper.
2. Related works
In this section, the related works in the area of cloud security
transparency are presented. The focus is to provide a flavour of the
essential contributions made by researchers. The review gives the reader
an understanding of the existing solutions and shortcomings of the
current state-of-the-art in cloud security transparency, as well as high­
lighting the contributions of this paper.
2.1. Security and controls in cloud
Several works focus on the security issues, attacks and controls in
cloud computing. Specifically, the effects of DDos attack in the cloud is
much more critical compared to traditional infrastructure. Salah et al.
2
Journal of Information Security and Applications 54 (2020) 102594
[10] proposed a cloud-based security overlay network using a set of
integrated security services that focus on the deployment of any security
software in the cloud to protect against attacks such as IDS, DDoS,
firewall. The underlying architecture of the proposed approach com­
prises security and management units and customer network’s protected
endpoints, including email and web servers, and production worksta­
tions. Sensors and agents are deployed at various points within the
customer’s protected endpoints to handle communication request from
the cloud-based overlay network using network-based IDS, DDoS pre­
vention systems, and email protection, and endpoint security and
vulnerability manager. Auto-scaling and elasticity methods are widely
methods for dealing with efficient usage of resources in the cloud ser­
vices. A simulation study performed by [11] focuses on the identifica­
tion of the optimal setting for scaling and elasticity. In particular, the
study determines the impact of CPU utilization threshold and scaling
size factors on the overall cloud service performance using various pa­
rameters, i.e., response time, the resource utilization, and used instance
cost. The result concluded that configuration parameters of the provi­
sioning mechanism have a considerable impact on the performance and
cost of cloud services and input load can be used to tune the upper CPU
utilization and scaling size. Virtual Desktop Cloud (VDC) – analyst tool is
presented by [12] to maximise users’ quality of experience without
additional resources provisioning. This novel tool uses Net Utility and
Service Response Time quality metrics for determining the readiness of
the VDC platform. The applicability of the VDC analyst tool is demon­
strated through use cases, and the result shows that users’ QoE can be
achieved by using the tool through optimizing net utility, estimating
values of service response time and load balancing. In [13] the authors
emphasised the importance of distributed security solution for a secure
Multi-Agent Systems(MAS). This work reviews the existing state of the
art relating to secure deployment of MAS and its application in the
various domain including e-commerce, e-health, control system and
military application. The review finally discovers two closely interre­
lated trends,i.e., secure MAS and security MAS for securing the
general-purpose MAS applications and distributed systems. A compre­
hensive review of security issues relating to existing attacks, re­
quirements, and solutions in IoT is performed by [14]. IoT devices
generally interconnect with many other devices. Therefore the paradigm
requires security consideration from low, medium and high levels of its
deployment such as privacy violation or DoS can impact all levels and
require various existing controls including secure communication and
M2M security. The review also advocates the applicability of blockchain
technology for addressing IoT security challenges such as blockchain can
be used for trustworthy and authorized identity registration of IoT
devices.
2.2. Security audit and assurance frameworks
A security audit is an essential aspect that deals with the assessment
and verification of controls to demonstrate that necessary protection
measures are put in place across all architectural levels in a cloud sys­
tem. There are several standards and best practices that serve as a
baseline for enabling security transparency in the cloud. One of the
leading institutions that focus on and best practice in cloud computing is
the Cloud Security Assurance (CSA), which is actively working on
several projects that are aimed improving cloud security transparency
such as Cloud Controls Matrix (CCM) [15]. CCM is based on established
standards, regulations and control frameworks for assisting potential
customers in assessing the security risks associated with a CSP. CSA also
has another project named Consensus Assessments Initiative Question­
naire (CAIQ) [16] whose goal is to provide customers with a list of
questions and answers to evaluate CSP offerings. Further, the Security,
Trust & Assurance Registry (STAR) [7] is another project by CSA that is
based on CCM and CAIQ, which provides a public database of CSPs that
have completed assessments based on CCM and CAIQ. STAR offers
different certifications such as self-assessment that is self-explanatory,
U.M. Ismail and S. Islam
certification and attestation that require an assessment by a third-party,
and continuous, which is based on continuous monitoring. Conversely,
compliance through certifications by security standards only provides a
periodic assessment for a timespan, but do not provide additional
feedback for intervals between assessments. Self-assessments prepared
by CSPs are self-proclaimed declarations that are usually tilted in their
favour, thus susceptible to bias, subjectivity, and failing to capture an
accurate impression of the authentic state of affairs within the envi­
ronment. Furthermore, there is a need for improved security trans­
parency concerning CSPs infrastructure and security protection
practices that goes beyond documentation, certifications, and agree­
ments using concepts of technical audits that are evidence-based driven.
2.3. Software agent and SLA monitoring
Ouedraogo et al. in [17] proposed one of the first solutions for pro­
moting security transparency in the cloud realm. Their contribution,
which is event-driven, allows both CSU and CSP to make specifications
to represent patterns of events, whose occurrence can be evidence of a
security anomaly or breach or merely a sign of nefarious use of the cloud
infrastructure by some of its users. Casola et al. in [18] also discussed a
preliminary design and implementation of a security solution for PaaS
based on SLA approach to address the issues related to the management
of security requirements in the cloud. The work adopts a dedicated
cloudware platform that is deployed over infrastructure resources. The
platform supports end-users and CSPs to specify their security re­
quirements by means of SLAs, evaluate security features offered by
remote cloud security brokers, management of SLA lifecycle as well as
the development and deployment of security services.
The works mentioned above are associated with several limitations.
For example, one problem deals with dynamicity, i.e. it does not mainly
focus on the areas of security that are of significant importance to the
cloud customer. The failure to appropriately harbour customer expec­
tations amounts to ineffectiveness to dispense transparency unless
otherwise done differently. Other transparency initiatives by the
research community either serve to provide a pre-assessment metric that
measures the transparency level of various CSPs before cloud services
are adopted or provide a mechanism by which cloud users ask for and
receive information about elements of transparency supported by a CSP.
The need for continuous visibility and transparent probing of activities
based on evidence is not considered. They also fail to acknowledge the
tendency of CSPs to generate a false representation of their services
without continuous verification. Another limitation deals with the
impracticability of attaining absolute transparency on all the clauses
within an SLA, which might be ascribed to the security or legal con­
straints that may restrain CSPs from making certain disclosures, as well
as the enormity or otherwise practicality of all areas of cloud security
that ought to be covered.
2.4. Industry practices and systems
Various vendors in the cloud industry have developed systems and
associated processes for distributed data collection for monitoring pur­
poses in cloud infrastructure. Most of these systems are mainly Security
Information and Event Management (SIEM) systems, which serve as the
means for detecting security events and collecting information from
various sources. For example, IBM developed QRadar SIEM [19] that is
available as a hardware virtual appliance and software packages based
on the customer’s event velocity. It includes several components such as
network insight, user analytics that addresses insider threat use cases,
and an advisor that provides automated root cause research for identi­
fied threats. In addition, Amazon CloudWatch [20] allows the moni­
toring of AWS resources and applications to run on AWS on real-time. It
is used to collect and track metrics, and automatically displays the
metrics being used by AWS service user, including the capability to
collect logs and set incident alarms. Many of such industry systems are
3
Journal of Information Security and Applications 54 (2020) 102594
well-established that have numerous strengths and weaknesses. How­
ever, many of such systems are designed to capture log data from a
specific area of the cloud infrastructure (such as network or database
activities), and the extent to which logging information is captured from
the cloud environment is dependent on the focus of the tool. They do not
provide vital information regarding other layers and heterogeneous
sources of the cloud stack
This paper attempts to address some of the research gaps identified in
the preceding literature by exploring and establishing essential concepts
that are necessary for the attainment of security transparency. It also
proposes an evidence-based driven technique for a comprehensive
assessment of evidence collected from various layers and heterogeneous
sources. The method leverages a specially designed tool that provides
users with the platform to specify essential security requirements that
are most important to their assets, based on which evidence regarding
the fulfilment of these requirements can be collected and evaluated
during using audit, which is perceived to improve assurance regarding
security transparency. The audit investigates how CSPs can conform to
sound data processing and requirement compliance to their customers
by comparing evidence against rules that govern data processing in the
cloud.
3. Methodology requirements for integrated security
transparency and audit framework
In this section, we aim to describe the essential requirements for
developing the integrated security STAF proposed in this paper. In other
words, the methodology requirements describe the conditions that must
be considered for the proposed STAF to address the existing research
gaps. As such, the requirements are mainly formulated based on the
review outcome of related works and identification of limitations in
state-of-the-art. Thus, the requirements are derived based on the
following:
• RQ1 - Conceptualisation of Security Transparency. The frame­
work shall enable the specification of concepts by which security
transparency can be modelled or perceived at different levels of
abstraction. It should capture the general concepts that constitute
security transparency and decompose these concepts into more
specific details.
• RQ2 – Specification of Security Transparency and other Re­
quirements. The framework shall enable the specification of secu­
rity transparency, technical business and other requirements that are
important for an organisation.
• RQ3 - Collection of Verifiable Evidence: It shall enable the
collection and analysis of evidence at all layers of the cloud stack,
CSP security and processes.
• RQ4 - Assessment of Evidence. An independent assessment and
verification of evidence should be supported for enabling indepen­
dent assessment of CSP conformance to requirement by a trusted
party.
• RQ5 – Determination of CSP Transparency Worthiness. The
framework shall enable the determination of the security trans­
parency worthiness of a CSP.
3.1. Methodology structure
The methodology structure, as shown in Fig. 1 consists of the con­
ceptual view, a process and a supporting audit tool. The conceptual view
comprises a set of concepts that are formed according to the principles of
security transparency using a meta-model. The process consists of
several activities that can be followed to implement the concepts at
organisational levels, such as the specification of security transparency,
assessment of evidence, and determining CSP’s conformance to re­
quirements. Also, the last component of the methodology is a supporting
U.M. Ismail and S. Islam Journal of Information Security and Applications 54 (2020) 102594

framework is a holistic set of abstracted ideas or rules that can be used to

Fig. 1. STAF methodology structure.
audit tool that enables trusted auditors to assess evidence produced by
the CSP, specify remedial actions and determine conformance levels met
by the CSP.
4. An integrated cloud security transparency and audit
framework
In this section, an overview of the proposed STAF is presented. A
solve a particular problem [21]. From software engineering perspec­
tives, a framework is defined as a set of classes that embodies an abstract
design for solutions to a family of the problem.
In our previous work [22], we proposed a cloud security trans­
parency framework (Fig. 2) to address the ever-increasing users need for
security transparency in the cloud. However, the previous work has not
provided a process that ought to be followed by users for implementing
the framework within an organisational context. Importantly, it has
neither provided detailed activities necessary for implementing the
framework nor a technique that supports continuous delivery and
enhancement of security transparency. Thus, this paper attempts to
extend our previous work by integrating other essential concepts and
proposing an underlying process for the implementation of STAF. Pri­
marily, the process aims to introduce different phases of activities that
organisations can follow for understanding and strengthening security
transparency by looking at essential considerations such as identifying
roles, assessing risks, and evaluating CSP controls.
4.1. Conceptual view of STAF
The meta-model in Fig. 2 shows an overall view of the concepts in
STAF and their relationships. The metamodel consists of essential con­
cepts such as actors, goals, assets, risks, requirements, evidence, security
audit, and assessment. An actor could be an organization and other
stakeholders. At the preliminary stages of cloud adoption, an organi­
zation performs an appraisal of the stakeholders that will be actively
involved, or whose interest should be taken into account. An organiza­
tion owns a wide range of assets that require several security goals for

Fig. 2. Cloud security transparency framework.

4
U.M. Ismail and S. Islam
supporting the business process. As a result, assets that are critical to the
operations are of an organisation are profiled, including the security
goal every asset must achieve, the business process supported by assets,
and the criticality level for each asset. Further, goals are specific attri­
butes that describe assets’ expected conformance to secure behaviour
such as confidentiality, integrity, and availability. In addition, assets are
usually connected to one or many forms of risks, especially as a result of
adopting cloud services. An organization systematically identifies the
risks that could affect its assets, associated threats, including a
Fig 3. Ontology View of Concepts in Protégé.
The process comprises of five primary activities namely.
5
Journal of Information Security and Applications 54 (2020) 102594
prioritized estimation of the likelihood, impact of security risk scenarios
and the security measures that can be applied to controlling to risks.
Diversely, CSPs implement necessary controls for safeguarding cus­
tomers’ assets, as well as transparency mechanisms for divulging in­
formation to customers regarding operational practices. Also, the CSP
adopts proactive or reactive transparency mechanisms to generate evi­
dence in various forms to support potential customers’ access to infor­
mation regarding its services or provide existing customers with
essential data, system or application report that can assist them in
U.M. Ismail and S. Islam Journal of Information Security and Applications 54 (2020) 102594

performing verifications. An organization considers CSP evidence, and Table 2

specify specific requirements that must be met. Therefore, requirements
are specified from different dimensions such as transparency, basic,
operational and business requirements. The requirements specified
become the major areas of attention to the organization that ought to be
monitored in the cloud, and therefore, the evidence must be provided on
how they are being satisfied. The audit plays a vital role to collect evi­
dence about requirements, including CSP conformance to such re­
quirements. Put differently a security audit aims at producing a clear
audit report based on findings from evidence to establish how well re­
quirements are met and how controls are operating.
Atomic linguistic rules of security audit.
Definitions
< Actor >< Specify><Requirements >to<Protect><Asset>
< Actor>< Provide >< SecurityControl>to<Protect><Asset >
<Actor >< Provide >< Evidence>to<Actor>to<Prove><Conformity>
<Actor ><
Assess><Evidence>to<Determine><Actor><Conformity>to<Requirement>
< Actor ><Create><AuditFindings>to<Provide><RemedialAction>
< Actor ><Enforces><RemedialAction>to<Prove><Conformity>

Table 3
4.2. Ontological representation of concepts Stakeholder analysis definition in SPEM.
Stakeholder Analysis
The methodology for the proposed STAF takes into consideration
Activity {kind: phase}: Stakeholder Analysis
some critical concepts that have been methodically identified. It is ProcessPerformer {Kind: primary}
therefore imperative to develop the security transparency ontology RoleUse: Security Analysis
which proves the foundation of the proposed framework. The motive WorkDefinitionParameter {Kind: in}
WorkProductUse: Identify Actors
behind developing the ontology was to create a knowledge base of se­
WorkProductUse: Identify Actors
curity transparency and its related concepts, which is mainly intended as WorkProductUse: Stakeholder Analysis
a source for common information access containing key concepts, re­ Work DefinitionParameter {Kind: out}
lations and axioms from the domain of security transparency. The se­ WorkProductUse: Security and Privacy Reference Diagram
curity transparency ontology is implemented using OWL, i.e., Protégé Step: Identify Actors
7.1.0 [23] is used. The ontology contains all the essential concepts with
associated subclasses, as shown in Fig. 3. However, due to limited space, properties that are to achieve, conformance level to be met, risks to be
the only a few semantic rules of the audit concept are presented in this eliminated and evidence to be provided. These rules are based on indi­
paper. vidual security audit concept. Therefore, Table 2 defines atomic rules
In Fig. 3, the concept SecurityAudit corresponds to the characteristics based on the definitions and indicates the sequential relations explicitly
that describe audit within the activities of the framework. Subclasses of among the security audit concept and its properties.
“AuditFindings” and “AudiatbleRequirements” have been defined to
reflect the corresponding instances of audit outcomes according to the
4.3. Process for STAF
audited requirements. Also, other subclasses have been defined, such as
“RemedialAction”, “Technique”, and “Evidences”. These are followed by
A process is considered as a structured set of activities that are
the formulation of assumption that “any security audit is performed on at
executed by an organisation towards accomplishing security trans­
least one requirement (“AuditableRequirement”), based on evidence (“Evi­
parency. The process manifests efficiency and adequacy for analysing
denceType, and EvidenceSource”) and criteria (“AuditCriteria”) to produce
the security aspects of cloud adoption and has the potential for
conformance (“ConformanceLevel”), fulfilling the purpose of conformance
enhancing trust and assurance in cloud services. An essential feature of
(“ConformanceLevel”) for enforcing remedial action “RemedialActions) by
the process is that most of the activities are formed by considering a
an actor (“Actor”).
variety of leading industry best practice, frameworks, guidelines and
standards that are generally applicable to all organisations regardless so
4.2.1. Semantic rules of audit concept
their size or the sector in which they operate. The process comprises of
In this section, we present a systematic process for implementing the
five primary activities namely; stakeholder analysis, define organisational
linguistic features of textual security transparency based on the ontology
context, risk management, requirement specification, and security audit.
defined in the previous section while focusing on a security audit. In
Each of these activities entails specific inputs and generates some out­
particular, features comprise the linguistic rules and keywords as shown
puts. For a more elaborate and comprehensive description of the pro­
in the remainder of this section.
cess, the activities in STAF process are specified using the OMG Standard
Based on the ontological representation of security audit shown in
SPEM 2.0. SPEM is a process meta-model that is mainly used to describe
Table 1, a collection of linguistic rules as linguistic features of a security
a software development process. The SPEM specification is structured as
audit is presented. We focused on atomic rules in terms of security audit
a UML profile and provides a complete MOF-based metamodel as shown
properties that are to achieve, conformance level to be met, risks to be
in Fig. 4.
eliminated and evidence to be provided .These rules are based on indi­
Activity 1: Stakeholder analysis
vidual security audit concept. Therefore, Table 2 defines atomic rules
Stakeholders are actors as top management, administrators, etc. who
based on the definitions and indicates the sequential relations explicitly
are directly or indirectly involved to influence the success of the orga­
among the security audit concept and its properties.
nization and its processes. The relevance of this activity is to obtain a
Based on the ontological representation of security audit shown in
comprehensive picture of actors and their roles in meeting requirements.
Table 1, a collection of linguistic rules as linguistic features of a security
Step 1.1 Identify actors
audit is presented. We focused on atomic rules in terms of security audit
Actors are the entities that will contribute to the cloud migration-
related decisions, interact with the cloud system or with one another
Table 1 through actions such as providing services to the organisation. The
Ontological representation of security audit.
listing of actors varies and will be determined in every organisation
No Definitions according to its volume of activities and resources.
1 SecurityAudit – – Requirement H ∃ achieve.Conformance H ∃ protect.Asset H ∃
– Activity 2: Define organisational context
fulfilled by.Evidence To successfully execute the process and achieve a sound cloud
2 AuditFindings– – RemedialAction H AuditJudgement
– adoption, it is important to perceive each organization from within its
3 AuditJudgementt – – EffectiveH AcceptableH DefectiveH
–
operational context. Tailoring the cloud migration to organisational

6
U.M. Ismail and S. Islam
Fig. 4. Process definition in SPEM.
context helps an organisation to ensure essential cloud migration factors
are considered, and in general, increase the likelihood of success. The
primary output artefacts of this business process details involving four
steps:
Step 1. Assets profiling
The purpose of this step is to enable profiling of assets in terms of
importance to the organization. Assets are specific units such as a
database, application or program that support the delivery and usage of
services offered by an organization. Important asset information can be
gathered by reviewing background materials, including independent
audit/analytical reports, interviewing cloud users, and physical obser­
vation of organizational assets.
Step 2: Identify assets security goals
Security goals are specific attributes, also referred to as security
principles, which describe assets’ expected conformance to secure
behaviour. Identifying security goals is an important consideration to
allow an organisation to determine what key principles of security must
be ensured for assets to be accessed or modified, during storage, pro­
cessing or transmission, by authorised systems, applications or in­
dividuals. The security goals also support determining asset criticality,
which further supports risk management activities. We have defined a
set of asset security goals every asset must aim to achieve, such as:
• Confidentiality: assets must be protected from disclosure or exposure
to unauthorized individuals or systems.
• Integrity: assets must be guarded against unauthorized modification
and alteration.
• Availability: assets must be accessed only by authorized users or
systems without interference or obstruction.
• Accountability: requires the tractability of actions, attack or in­
cidents that occur to an asset to the responsible system or actor.
• Conformance: assets must operate as intended without variation to
expected behaviour, functions and regulatory requirements.
7
Journal of Information Security and Applications 54 (2020) 102594
Step 3: Determine asset criticality
Determining asset criticality involves prioritising and developing
actions that will reduce risks to the asset, improve asset reliability, as
well as defining cloud strategy in terms of the suitable cloud deployment
and service model that should be adopted. Therefore, determining asset
criticality is done by using an evaluation method that is developed ac­
cording to a criticality assessment criteria to distinguish critical from
non-critical assets as follows:
• Firstly, an impact value is applied to determine the importance of
assets based on perceived importance and the consequences of a
compromise to a particular security goal. The impact value uses a
numerical scale between 10 and 1 to represent levels between high to
low importance, respectively.
C + I + AV + AC + C
Impact Value = (1)
5 (No. of Goals)
Where: C = confidentiality, I = integrity; AV = availability; AC =
accountability; C = conformance
• Secondly, all assets are assigned a weighted score to reflect the value
of the assets and importance in the operations or business functions
of the organization. The assignment of asset weight score is done
using a range between 1.00 and 0.01. A score range between 0-81-
1.00 is considered “Extreme”, 0.61 - 0.80 = “High”, 0.60 - 0.41 =
“Medium”, 0.40 - 0.21 = Low, and 0.20 - 0.01 = “Very Low”
respectively.
• Thirdly, an equation for asset criticality is applied to determine the
overall criticality of assets. The equation considers assets impact
value and assets weight as:
Criticality = Asset Impact Value ∗ Asset Weight Score (2)
• Lastly, after the criticality of the asset is determined, the result is
compared to a scoring scheme to identify the criticality level that is
associated with an asset and the required level of protection needed.
A range between 8.00 – 10.0 = “Highly Critical”, 4.00 – 7.99 =
“Moderately Critical”, and 0.01 – 3.99 = “Low Criticality”
Activity 3: Risk management
Risk management activity identifies and measures the risks related to
the assets, as well as identifying essential controls for mitigating the
risks. Based on the assets identified in the previous task, all possible
threats that could negatively impact the assets are profiled in a register.
We have proposed two steps for risk management involving: (i) the
determination of threat profile; and (ii) creation of a risk register
Step 1: Determine threats profile
The determination of threats requires a structured representation of
threat information that is expressive and all-encompassing due to the
dynamicity of the cloud environment. It is imperative to use a sound
approach that enables them to gather valuable insights based on the
analysis of situational and contextual threats that can be tailored to the
organisation’s specific threat landscape and its industry. Our approach
adopts Microsoft’s models for the threat model called STRIDE [24] and
impact rating called DREAD [25]. STRIDE is an acronym formed from
the first letter of Spoofing, Identity, Tampering, Repudiation, Informa­
tion Disclosure, Denial of Service and Elevation of Privilege that is used
for describing known threats according to the type of exploits that are
used. In addition, DREAD stands for Damage potential, Reproducibility,
Exploitability, Affected Users, and Discoverability. By using the DREAD
model, the impact rating for a given threat can be determined. Publicly
available sources of threat information are explored for identifying
threats.
U.M. Ismail and S. Islam
Step 2: Create risk register
A risk register is an important document that provides a tentative
record of potential risks in line with threat profile, assets and security
goals [26]. To ensure consistency and relevance of risks and their
impact, we recommend that OWASP risk methodology [27] be used.
OWASP methodology is recommended for use because it estimates risks
from business process and technical perspectives, highly adaptable and
applicable to most organizations of all size. Six simple phases that
include the factors that make up the likelihood and impact of each risk is
included.
Phase 1: Identify risks
A workshop can be organized involving stakeholders from within the
organization to discuss the risks and arrive at a conclusion about the
general perception of risks and their impact on the organization. In
addition, risk details from multiple sources can be considered such as the
Open Web Application Security Project (OWASP) which maintains a
regularly-updated list of most pressing cloud security risks and has
recently released a Cloud Top 10 Security Risks [28]. In addition, Eu­
ropean Network and Information Security Agency [29] provided a list of
cloud security risks comprising 35 risks that fall under one of such cat­
egories as technical, policy and organisational, legal and non-cloud
specific risks.
Phase 2: Estimating risk likelihood
After potential risks have been identified, the next phase is to esti­
mate the likelihood of the risk occurring. Likelihood estimation provides
an approximation of how likely it is for risk to occur. OWASP has pro­
vided several factors that can help to determine the likelihood.
Phase 3: Estimating impact
In terms of estimating the impact of risks, assessment is inclined
towards the security goals of an asset that include confidentiality,
integrity, availability, accountability and conformity. The aim is to
provide a rough estimate of the magnitude of the impact on security
goals if a risk occurs
Phase 4: Determine criteria for severity of risk
This phase involves using criteria for defining the likelihood estimate
and impact estimate in order to calculate the overall severity for the
risks. OWASP methodology [27] uses a distributed scale of 0 to 9 for
both impact and likelihood rating.
Phase 5: Define control measures
Control measures are technical, administrative and procedural
safeguards that can be used to prevent, detect, minimize or counteract
security risks. Control measures are important for risk management
activities. An essential consideration is that security principles and
practices must be adapted for ensuring compliance at every stage of the
cloud usage [35]. To facilitate the incorporation of best-security prin­
ciples, it is important to leverage existing methodologies such as Se­
mantic Analysis Pattern [36] accommodate strict requirements. Such
methodologies support people with less technical and security skills to
identify security controls. Hence, various industry standards provide
recommendations on fundamental security controls are considered. For
example, Critical Security Controls [30] publishes a set of 20 controls
and best practice guidelines that are not only limited or specific to cloud
computing and which organizations should adopt to control known
computer security risks. Thus, to define control measures, we recom­
mend that risk control measures are selected from the predefined list
provided by CSC CIS [30]. CSC CIS provides 20 controls categorized into
3 prioritized and defence-in-depth set of best practices that are imple­
mentable and usable to mitigate attacks against systems and networks.
Further, ENISA [31] provides 27 baseline security controls that are
more CSP-oriented and focuses on control measures that protect cloud
computing systems against operational risks. It provides a high-level
security objective for CSPs with different levels of implementation of
security measures. The controls provided by ENISA’s are particularly
used to supplement CSC CIS, and it provides expansive controls that are
more specific to the cloud. Therefore, to choose security control mea­
sures, matching is performed where each control in CSC CIS is aligned to
8
Journal of Information Security and Applications 54 (2020) 102594
controls in ENISA to make a parallel matching and identify semantic
equivalence between them. The main aim of the matching is to compare
security control measures from CSC CIS to ENISA, identify and filter that
completely cover each other in terms of scope. The elements that are
used for the comparison include the name of control measure, type, and
the keywords. In such cases, if control measures are discovered to be the
same, then CSC CIS controls should be used. However, if there is no
similarity, control measures from both CSC CIS and ENISA should be
adopted. This approach ensures contents are compared more thoroughly
and risk control actions consistently easily identified.
Activity 4: Requirements specification
This activity focuses on establishing broad security controls that do
not only focus on addressing security risks but also other ensuring cloud
security and transparency. In identifying requirements, the important
spectrum of cloud operations is considered such as security transparency
requirements, baseline security requirements, migration security re­
quirements, compliance requirements etc. By considering all aspects of
security requirements, the audit will be more comprehensive and elab­
orate to cover the verification of many aspects of an organisation’s re­
quirements. Therefore, the primary objective of this activity is to specify
essential security requirements that mandate the presence of control
measures around assets are reiterated and identified to ensure sufficient
coverage in the management of cloud services.
Step 1: Specify transparency and other requirements
In this step, the actual requirements that serve as essential con­
straints that must be satisfied by the CSP are specified. The requirements
are primarily specified according to four different aspects: security
transparency requirements, baseline security requirements, business
requirements, and operational security requirements. The requirements
are derived from well-known industry framework to support a set of
accurate and verifiable implementable controls that are based on stan­
dard practice. Essentially, industry-acclaimed C SA CCM Version 3.0.1
[15]. CSA CCM provides sixteen essential security principles that guide
CSPs should implement and also provides organisations with the struc­
ture to achieving asset security in the cloud-tailored environment.
Activity 5: Security audit
This activity introduces an ongoing audit process that is aimed at
enabling organizations to examine whether the CSP continuously and
effectively implements plans, procedures and controls that meet orga­
nizational security requirements for protecting assets. It is aimed at
collecting evidence, independent evaluation of CSPs fulfilment of se­
curity transparency and controls, and preparation of a substantive audit
report. The activity consists of three main steps: (i) define the security
requirement to be audited; (ii) collect evidence in respect of the security
requirement; (iii) analyze evidence; (iv) and issue a report. The steps
involved are described below:
Step 1: Define the requirements to be audited
This step specifies the focus and depth of the audit in terms of the
specific requirements and CSP security controls that are subject to audit.
Hence, the security requirements specified in the preceding activity are
considered and become the focal point of consideration. Also, it allows
the collection of evidence that is most relevant for the control areas
under scrutiny.
Step 2: Collect audit evidence for the requirements to be audited
This step involves gathering evidence or historical records about the
CSP’s platform to assert proof of conformance to requirements earlier
specified. Evidence is reliable, relevant and sufficient physical or elec­
tronic records, computations, and client or third-party representations
about the implementation of processes, procedures and mechanisms
needed to secure the cloud platform and fulfil requirements. Audit evi­
dence is compared criteria to allow the security auditor to produce audit
findings and present audit conclusions.
Phase 1: Technique for evidence collection
A checklist is designed to aid the collection of evidence. The checklist
comprises a series of questions that are relevant to the security re­
quirements. The questions in the checklist are formed by considering the
U.M. Ismail and S. Islam Journal of Information Security and Applications 54 (2020) 102594

industry-accepted initiative, namely Consensus Assessments Initiative Table 4a

Questionnaire (CAIQ V3.0.1) [16] and Centre for Internet Security Define organisational context in SPEM.
Critical Security Controls (CIS) [30]. CAIQ provides a series of questions Defining Organisational Context
that are aligned to control areas of CCM and which an auditor may ask of
Activity {kind: phase}: Defining Organisational Context
a CSP in assessing the capabilities and competencies of the CSP. On the ProcessPerformer {Kind: primary}
other hand, CIS provides recommended sets of actions and best practices RoleUse: Security Analyst
for controlling most common attacks against systems and networks. The WorkDefinitionParameter {Kind: in}
CSP responds to the questions with ‘Yes’, ‘No’ or ‘Not applicable’. Where WorkProductUse: Organization Policies
WorkProductUse: Oganization Requirements
‘Yes’ response is obtained for a specific question in the checklist, the CSP Work DefinitionParameter {Kind: out}
must produce evidence to support their assertion with respect to that WorkProductUse: Organisational Context List
question. A ‘No’ and ‘Not applicable’ answers do not require supporting Step: Assets Profiling
evidence from the CSP. Step: Security Goals
Step: Asset Criticality
Phase 2: Evidence types
There are different types of evidences that can be collected, and each
varies according to the requirement being audited. Some evidence per­
tains collecting security and event logs, while other evidence entails Table 4b
proof of CSP certifications/accreditation from standards/frameworks. In Assessment parameter.
terms of security and event logs, the focus is placed on logs about ap­ Label Code Value Meaning
plications, user activities, and security incidents etc. which contain in­ Very High Vh 1.0 Highest level of conformance to a given
formation related to events that have occurred within the cloud requirement
environment. Such logs are generated by many cloud components, High Hg 0.9 The high degree of conformance to a given
including penetration testing, vulnerability scans, intrusion detection requirement
Medium Md 0.6 Average degree of conformance to a given
and prevention systems, servers, applications and network equipment.
requirement
Step 3: Perform security audit Low Lw 0.3 The lowest degree of conformance to a given
Once evidence is collected, the audit work is performed in accor­ requirement
dance with ISA 200 and ISA 402 [32] standards. Specifically, the audit Nonconformance NCom 0.0 Non-conformance to a given requirement
involves analyzing evidence in an attempt to evaluate and establish
conformance or nonconformance of CSP controls i.e. determine whether
assigns a value from a range of 0 to 1, where 1 represents the best
security procedures and practices in the CSP’s environment can suffi­
possible score and 0 represents the worse score. The auditor-assigned
ciently safeguard assets and comply with security requirements of the
weight for the xth requirement is multiplied by the corresponding
organization. To achieve this, the checklist created in the previous
score assigned by STAT based on the audit criteria. Each control domain
serves as the reference for reviewing CSP practices and the extent to
may have m number of control type (CT). For example, the value of the
which the CSP conforms to the organization’s requirements. The
ith control domain can be defined as the sum of the m number of control
checklist consists of the requirements that are subject to verification, the ∑m
type such as SVCD = x = 1 CTX where the value of each control
target verification (control domain), base measure (control type),
requirement is bounded as 0 ≤ CT ≤ 1. Therefore, by taking the these
specification and the corresponding question concerning the target
into account, a formula is applied to determine the conformance level of
verification. It also consists of CSP responses, means of verification, the
the CSP as shown in (1).
audit criteria that are used for evaluating evidence and finally, the
[ ∑n ]
conformance level associated with the CSP. i = 1 CTx WCTi, Cod
index = 100 (1)
Phase 1: Apply audit criteria n
Audit criteria is a set of procedures, policies, specifications, or re­
quirements used as a reference against which evidence are compared where:
against. The audit criteria can be qualitative or quantitative, general or
specific, focusing on what should be according to laws regulations or • n represents the total number of control types considered in the
objectives, sound principles, scientific knowledge or best practices [32]. conformance level calculation
∑
In performing an audit, justifiable audit criterion is defined or selected • SVCD = m x = 1 CTX = CT1 + CT2 …. + CTm where m represents the
from standard procedures and policies. total number of control types for each control domain
Phase 2: Determine conformance level • The value of the control domain can be bounded as 0 ≤ CT ≤ 1
Essentially, to establish the conformance level of a CSP, a thorough • Cd represents the code for the auditor-assigned weight for the control
assessment of all evidence presented is performed by STAT in respect of domain as shown in Table 4.
the requirements earlier specified. An evaluation rule is created, where a
security auditor, based on expert analysis and interpretation determines Step 4: Report Audit Findings
the level of conformance that is associated with a CSP based on the An audit report is a written opinion or decision of an auditor based
evidence provided. The security auditors are assumed to be experts and on overall findings. It is the primary means for communicating results of
able to validate and determine the appropriate scores for each evidence the audit to relevant actors, and in some instances, also shared with to
based on the requirements of the organization. The metric comprises a the CSP. The report focuses on requirements that have been assessed and
range of assessment parameters that the auditor can assign to determine the degree to which they have been met by the CSP. Once these con­
the conformance level of a CSP as shown in Table 4. For each control siderations are established, remedial actions that must be implemented
domain (CD), an auditor assigns a weight x that is represented as W(CDx, by the CSP or the organisation are drawn by the auditor. The remedial
Cod), where CDx represents the weight of xth control domain and the Cod actions take different perspective including, actions that are designed to
represents the code as per Table 4 (assessment parameter). The auditor pre-empt irregularities before they occur; actions that identify irregu­
assigned value for the xth control domain is multiplied by the corre­ larities, threats or errors on a timely basis after they have occurred;
sponding value assigned by STAT, SVCDx, which can be extended for a actions that correct irregularities or risks and prevent further reoccur­
system with n number of factors such that: Control type 1 →. W(CDx,Cod), rence; or auditor statement indicating sufficient and satisfactory con­
Control type 2 →. W(CDx,Cod), Control type n →. W(CDx,Cod), trols not needing further actions. To ensure consistent reporting in
Furthermore, for each control domain, the tool determines and accordance with an established process, the audit report is developed

9
U.M. Ismail and S. Islam
based on the provisions and in compliance with information security
audit standards and audit protocols.
Audit conclusion/judgement
This provides an overall judgement regarding audit findings in
respect of each requirement and the CSP’s security controls. There are
three types of judgements that an auditor, having obtained sufficient
audit findings, can issue to establish their actual judgment, which
includes:
• Defective Practice: this type of judgement is presented in cases where
the audit findings substantially indicate material disparities between
audit criteria and CSP asserted evidence. From another perspective,
defective controls are audit findings where adequate controls are not
in effect, or there is reasonable doubt that security requirements are
being met.
• Acceptable Practice: this judgement is issued when audit findings
indicate similarity between audit criteria and CSP assert evidence,
but there are disparities or weaknesses in certain areas. In another
perspective, acceptable controls imply audit findings where security
controls are in place to provide acceptable assurance. However,
controls need to be tightened or improved in some areas.
• Effective Practice: judgement is presented when audit findings
indicate a substantial correlation between audit criteria and evi­
dence. From another perspective, effective controls manifest the
presence of all security controls, procedures and practices are in
place in accordance with relevant security requirements and appli­
cable criteria.
Remedial action:
Action plans are constructive recommendations issued by the auditor
when significant improvements in operations and performance of the
CSP as substantiated by the audit findings. From both the CSP and
organizational perspective, remedial actions are recommended to make
sure necessary actions are implemented to address the lack of fulfilling
requirements or insufficient controls.
• Preventive: include security control measures, policies, and proced­
ures that are to deter or prevent security incidents, risks, errors, or
omission of requirements from occurring.
• Detective: technical and nontechnical security controls, policies,
procedures that detect errors or incidents and provide visibility into
malicious breaches and attacks.
• Corrective: technical implementations and procedures that mitigate
damage, correct errors or incidents once they have occurred.
5. Security transparency and audit tool (STAT)
STAT is a supporting audit platform that auditors can use to perform
the cloud security audit. It is designed to enable auditors to leverage a
security audit checklist and probe CSP services, collect and analyse ev­
idence, and produce findings regarding CSP’s conformance to re­
quirements as shown in Fig. 5. This process is enabled through a query-
response approach that is initiated and controlled by an auditor on
behalf of any organisation, where the CSP responds to a request by
supplying relevant evidence.
5.1. Assessment rules used STAT
Important assessment rules have been designed for use by STAT to
provide the basis for computing an appropriate conformance level of
CSP to an organisation’s requirements. The rules consider the inputs of
security auditors for the requirements, control domains and control
types based on the evidence provided by the CSP.
Rule 1: For all control domains CD1, CD2… CDn. if the conformance
level of control domains in requirement A are the same as those of re­
quirements B, then the overall conformance level of requirement A
10
Journal of Information Security and Applications 54 (2020) 102594
Fig. 5. STAT workflow.
should be equal to that of B. Assume we have control domains in
requirement A with a set of CD = {CD1, CD2… CDn.}o, where CD rep­
resents the xth control domain, the compliance level for requirement A
on the control domain CDx is represented as CCDx A whereas the overall
compliance level of requirement A is COverall
A . This rule is formally defined
as If ∀ CDi ∈ CD, CCDi
A = CCDi
B ⇒ COverall
A = C Overall
B
Rule 2: For control domain CD1… CDk, if requirements A and re­
quirements B have the same compliance levels, and for other re­
quirements CDk + 1, … CDn, the compliance level for requirement A are
higher than those of requirement B, then the overall score of A should be
higher than that of B. This rule is formally defined as:
If ∀CDi ∈ { CD1, . . . CDk}, CCDi
A = CB and
CDi
∀CDx ∈ {CD1 + 1, . . . CDn}, CACDx > CBCDx ⇒ CAOverall > CBOverall
Rule 3: For control domain, CDi, for which the compliance level of a
requirement A is higher than that of requirement B, and also there exists
control domain CDx, for which the compliance level of requirement A is
lower than that of B.
Rule 4 : If there exist m requirements (R1, R2, … Rm) where m > 2,
the overall compliance score between requirements will follow the 2
previous rules outlined above, which is formally defined as:
Given multiple requirements such as (R1, R2… Rm),
for p = 1: m – 1
for q = p + 1 : m
compute COveral and COveral following rule 1 ~ 2
p q
5.2. Features of STAT
STAT focuses on an evidence-based way of probing, assessing and
reporting of findings relating to CSP conformity to requirements. The
main features provided by the tool include three main dashboards
consisting of essential functions that can be performed. Each function­
ality contains important components of a security audit. The three main
features include administrative client; security auditor; CSP dashboards.
A. Administrative dashboard
The purpose of this feature is to provide administrative and user
management functions in terms of authentication and providing audi­
tors and CSPs access to the STAT platform. The administrative dash­
board enables the auditor to manage logs and user activities in terms of
reviewing auditor activities and CSP profile. In addition, it allows the
U.M. Ismail and S. Islam Journal of Information Security and Applications 54 (2020) 102594

management of enquiry from the CSP who may have some questions,
complaint, suggestion, submission of requirements or checklist etc.
regarding the assessment. Among other functions, the administrative
dashboard allows the auditor to maintain the overall system security,
functionalities and definition of user access rights; creation of user ac­
count; management of auditors assessment invitation to CSPs; control of
audit platform; verification of CSP details and assessment invitation
before being sent out by security auditors; notification services on
completion of assessment, CSP response management, and acknowl­
edgement of remedial plans by CSP.
B. Security auditor dashboard
This dashboard provides an auditor with the functionalities to
perform a systematic assessment of CSP’s conformity to requirements as
shown in Fig. 6. It consists of many features that enable the auditor to
define the requirements that will be audited, prepare security audit
checklist, initiate the assessment process, gather and evaluate evidence
from a CSP, establish and communicate the findings, and recommend
remedial actions upon the completion of the assessment. Another Fig. 7. CSP response to checklists.
important functionality is to enable an auditor to initiate the security
audit by establishing contact with an inviting the CSP to commence the
response. This task can be done by uploading and submitting docu­
audit. This is achieved using an assessment invitation form that is
mentary evidence that supports the CSPs’ assertion. Further, the dash­
embedded in the tool and managed by STAT administrator. The form
board allows the CSP to enquire the assessment or any other form of
consists of essential details including the CSP’s name, the email address
question they may have for the auditor. Lastly, audit findings and
provided and the requirements that are being audited. It is followed by
remedial actions recommended by the auditor are received by the CSP
an email being sent to the CSP’s containing a secure hyperlink and ac­
through this dashboard, who in return acknowledges and report back on
cess credentials. Essentially, the auditor dashboard also provides an
the measures being taken to address the recommended actions.
interactive page for access a checklist that is composed of a predefined
set of questions, which is stored in the STAT platform. The focus of the
6. Deployment architecture for the proposed framework
checklist is the requirements that will be audited, with each requirement
consisting of standard properties such as control domain, control type,
This section provides a deployment architecture for the proposed
question, CSP/user response and the type of evidence supplied by the
framework
CSP.
Fig. 8 shows a deployment architecture of the proposed framework,
C. CSP dashboard
highlighting the interaction between a CSP, a CSU (an organization),
The goal of this module is to provide a CSP with the capabilities to
and the role of an independent auditor in the validation and verification
take part in the audit process by responding to questions in the checklist.
of evidence using secure multi-agent system (MAS) [34]. MAS provides
In other words, it allows the CSP to answer the checklist with a view of
basic security measures within the architecture by supporting authen­
providing evidence and enabling the cloud auditor to assess responses
tication, authorization and accountability, including privacy and
and evidence provided as shown in Fig. 7. Literally, once the CSP
integrity of data during the exchange of data. The rationale behind
acknowledged the audit invitation sent by STAT administrator, access
adopting MAP is to facilitate secure communication between the actors
permission is granted using credentials issued by the administrator. The
(using agents) and maintain a high level of trust, assurance and
checklist then appears as a form, covering the requirements that have
dependability. Hence, the multiple agents are deployed and collaborated
been earlier defined by the auditor. The CSP answers the set of questions
to analyze the exchange of information and detect possible intrusion
relevant to each requirement that allows them to toggle between two
activities with respect to evidence sharing that takes place on the plat­
choices – ‘Yes’, ‘No’ or ‘Not Applicable’. In addition, the evidence must
form. These agents enable significant protection of the platform by
be supplied by the CSP for every question that is answered with a “Yes”

Fig. 6. Creating a checklist.

11
U.M. Ismail and S. Islam
Fig. 8. Deployment Architecture of the proposed framework.
ensuring privacy, integrity and confidentiality of data.
Hence, the deployment architecture comprises of three main layers
(i) user requirements specification, (ii) CSP evidence generation, (iii)
and evidence validation and verification. The user layer allows an or­
ganization to specify crucial requirements needed to protect assets (such
as access enforcement, DoS protection, cryptographic key & manage­
ment, communication security etc.) categorized according to trans­
parency, business, baseline and operational requirements. The exchange
mandates the provision of essential evidence from the CSP to demon­
strate compliance with meeting these requirements. The second layer is
the evidence generation. This layer supports the CSP to disclose security
practices, confirm compliance and provide evidence such as security
event logs, access logs, change management logs, monitoring logs, etc.
concerning the organisation requirements. This evidence is assessed to
determine conformity with user requirements and whether they match
control expectations from organization requirements standpoint. Hence,
the evidence validation and verification layer allow an auditor to apply
independent procedures for establishing that the evidences conform to a
high degree of reliability, and provide assurance that imposed condi­
tions are met. The verification and validation exercise employ two
different techniques, namely tool oriented and third-party certification
techniques.
7. Evaluation
This section discusses the applicability and validity of our work by
focusing on a real use case. Two different methodologies are used to
perform the evaluation. Firstly, empirical investigation is used to
demonstrate the applicability of the work, while questionnaires were
developed based user acceptance of computer technology [33] and
perceived ease of use technology acceptance model [9]. The question­
naire aims to collect and evaluate stakeholders’ opinion about the rel­
evancy of STAF to support transparency, and to determine the
effectiveness and acceptability of STAT. The rationale behind forming
the evaluation criteria on these two models is that they are both widely
used for assessing organisation-level adoption of various information
systems products and services.
12
Journal of Information Security and Applications 54 (2020) 102594
7.1. Case study background and existing functions
The case study is based on an anonymized company that specializes
in property management in London. The company operates across
multiple locations, with a total of 6 operational sites, 5 functional de­
partments and a workforce of more than 100 employees. The company
also has more than 2,000 properties under its management. The com­
pany uses an open-source enterprise content management (ECM) system
that runs on PHP (server-side scripting language). The staff worked with
an ever-expanding document management solution (DMS), which was
designed initially to complement their existing ECM software. DMS is
designed for capturing, archiving, indexing and retrieving data. It also
enables the staff of the company to collaborate and manage the creation
and flow of documents in a centralized repository, providing solutions
for gaining greater control of their business documents, information and
processes. It is a web-based modular architecture that is built on
Microsoft’s supported products and is deployed on servers located in the
datacentre of the company. These include Windows Server 2003/2008
that serves as a document management server; Visual Studio for contents
development; an SQL database that is used for storing and retrieving
data. In particular, the system is implemented using.Net v.4 framework
and other programming languages such as JavaScript for building many
different frontend applications used by the company.
7.2. Data collection and analysis
At the initial stages of implementation, the kick-off workshop was
conducted at the case-study contexts. The workshop was attended by
senior management representatives and IT personnel with at least four
years of working experience. The primary aim was to specify the role of
stakeholders during implementation exercises and in providing feed­
back through the questionnaire. An overview of the process for STAF
and the essential features of STAT was provided to help stakeholders
develop an understanding of how the process/tool works, expected de­
liverables, procedures, and the methodology involved for data collec­
tion. Thus, a total of 18 printed versions of the questionnaires were
distributed to participating stakeholders. Stakeholders were introduced
to the aim of the project and how their feedback could contribute to­
wards validating STAF/STAT and the overall research findings. They
U.M. Ismail and S. Islam
were briefed about the evaluation criteria that have been considered in
forming the questionnaire. Also, it is worthy to emphasize that the
possible responses are designed to fit the purpose and can be indicated as
either “I strongly agree”, “I agree”, “Not sure”, or “Disagree”. Thus, a
total of 18 printed versions of the questionnaires were distributed to
participating stakeholders. Overall, a total of 16 questionnaires were
returned, implying a response rate of 88.8%.
7.3. Application of the STAF and STAT to the case study
We had the opportunity to apply the proposed STAF process to
determine its relevance to a real-life context. As part of managing the
entire implementation process, the company assigned a team of pro­
fessional stakeholders to guide the execution of the entire imple­
mentation process, as well as ensuring necessary support to make sure
implementation is achieved optimally. Hence, before starting the ac­
tivities, we indulged in a business rules discovery process that enabled
us to perform a preliminary study of the company and existing systems.
A meeting was organized where the overall implementation plan is
decided, a project team developed, and the first steps were taken to­
wards establishing the activities of the process. The project team com­
prises representatives from senior management, the IT department and
other stakeholders within the company, all of whom have more than 4
years’ experience. The implementation process was performed through
a series of organized meetings, workshops and discussions as presented
below.
Activity 1: Stakeholder analysis
a. Identified actors
During the preliminary meeting and interaction with stakeholders,
we have been able to identify the key actors that will support or influ­
ence the project and the different roles they play within the organiza­
tion. This is mainly done by considering actors internal and external to
the company. The list of actors identified are summarized as: 1) internal:
senior management representatives, security auditors, security analyst,
and system administrator; 2) external: CSP, cloud broker.
Activity 2: Organisational context
Step 1: Assets profiling
Internal actors were involved to explain and document the system
and its components, which provided the basis to identify assets and their
security needs. They also presented a comprehensive overview of the
code repository, which will be the target of analysis, from where we
observed that the system comprises many different components. Based
on these discussions, we analysed the architecture of the system with a
view of identifying all dependencies, including how information is
stored, processed and transported.
Step 2: Security goals
The security analyst conducted a high-level brainstorming exercise
together with other team members to identify the most important se­
curity goals for the assets identified in the previous step. Hence, the
project team focused on security goals based on the system’s known
characteristics and the attributes of security goals that include:
• Confidentiality: confidentiality goals are intended to ensure that no
unauthorised access to data, application and other assets is
permitted, and that accidental disclosure is not possible. Information
or data on all the system’s components should be restricted to only
those with the permission to access.
• Integrity: it must be ensured that data and applications of the DMS are
safe from unauthorised modification and can be modified only by
authorised users. It also ensures the accuracy and completeness of
records and only authorised users should be allowed to modify
contents.
• Availability: data and resources must be made available for author­
ised use without interference or obstruction. Data, application, and
other system resources must be available when requested and easily
accessible to authorised users.
13
Journal of Information Security and Applications 54 (2020) 102594
• Accountability: the ability to trace activities or operations that occur
to data, applications or system components to a particular source. All
users must be accountable for the operations they have performed.
• Conformance: the system must operate as intended without variation
to expected behaviour, functions and regulatory requirements. The
system must be also secured from vulnerabilities that can be
exploited to cause unwanted behaviour.
Step 3: Assets criticality
The criticality level is determined and assessed in greater detail as
part of the asset profiling activity. Critical assets are those that are
essential for supporting the DMS and the operations of the company. The
security analyst determined the criticality of assets by applying a broad
evaluation method proposed in the STAF process. The step is conducted
as a separate brainstorming exercise, and the main goal is to determine
the criticality of the assets, which was formally approved by all project
team members. Table 5 shows the identified assets criticality from the
study context based on the identified asset.
Activity 3: Risk management
Step 1: Threats profile
A detailed list of threats based on the context is presented in Table 6.
They considered a list of security threats compiled by ENISA and CSA.
Firstly, the team started with identifying a combined list of 10 security
threats that they perceived to be important to the company’s assets.
Secondly, the previously short-listed security threats had to be ranked.
STRIDE and DREAD models were introduced to the participants to get an
understanding and formal approval of the methodologies that will be
used for ranking the threats. The team used STRIDE model to identify,
and evaluate threats for determining whether they fall into any of such
categories as spoofing identity; tampering with data; reputation; infor­
mation disclosure; denial of service; and elevation of privilege. More­
over, DREAD model is used for determining impact rating for the threats
by asking the participants a set of questions according to damage po­
tential, reproducibility, exploitability, affected users, and discover­
ability of threats. This activity also organised as a workshop involving
the risk management team members who decide and establish security
controls from different perspectives that must be met by a potential CSP.
The requirements for the case-study context are specified according to
four fundamental categories, namely: security transparency, baseline
security, business and operational security requirements. Due to limited
space, a detailed list of requirements is not provided in this paper
Activity 4: Requirements specification
This activity also organised as a workshop involving the risk man­
agement team members who decide and establish security controls from
different perspectives that must be met by a potential CSP. Therefore,
based on the application of the previous activities, the stakeholders
identified numerous requirements that are essential for the security of
assets and ongoing probing. The requirements are specified according to
four fundamental categories, namely: security transparency, baseline
security, business and operational security requirements. It is important
to mention that the requirements are listed according to the provisions
of security controls from CSA CCM as shown in Table 6.
Table 6: List of Requirements
Activity 5: Security audit
A workshop is organised and the steps involved in the audit activity
are introduced to the participants. They are briefed about the features of
STAT, shown how a security checklist is created and used; how evidence
is collected; how to audit criteria is formed; how to determine confor­
mance level; how audit findings are established; and how a report is
generated.
Step Implementation of STAT
A training workshop was organised, and stakeholders were given
training on the practical implementation, installation and application of
STAT, including the many dashboards that provide essential function­
alities. Also, in a walkthrough conversation, a representative agent
assigned by the CSP to support the company in performing the security
U.M. Ismail and S. Islam Journal of Information Security and Applications 54 (2020) 102594

Table 5
Assets criticality.
ID Asset Name Business Process Security Goals Asset Criticality Required Protection

Low Moderate Critical Basic Average Significant

01 Document management server Assets and content management Availability * *

Integrity
Authentication
Conformance
02 Databases Assets and content management Integrity * *
Confidentiality
Availability
Accountability
Conformance
03 Company and customer data Operations and services Integrity * *
Confidentiality
Availability
Conformance
Accountability
04 Web & application Servers Web contents managements Availability * *
Integrity
05 Frontend Application Service delivery Availability * *
Accountability
Integrity

audit was equally briefed about the steps involved and how to use STAT.
The features of STAT are thoroughly explained with particular focus on
the CSP dashboard that can be used by the representatives to accept
audit invitation, answer the checklist and upload evidence where
applicable, as well as receiving audit findings.
After the performance of the security audit and assessment of the
evidence, the audit team embarked on establishing the conformance
level of the CSP to ensure that findings are coherently presented to top
management. In all areas of the 4 requirements, the audit team deter­
mined conformance levels ranging from “very high” to “nonconfor­
mance”. A summary of the conformance levels according to each
requirement as well as the overall conformance levels discovered by the
auditors is provided as:
• 58% of requirements assessed to be high conformance
• 7% of requirements assessed to be high conformance
• 18% requirements assessed to be medium conformance
• 5% of requirements assessed to be low conformance
• 12% of requirements assessed to be conformance
Also, Fig. 9 provides a summary of the overall conformance levels for
all the requirements that have been assessed.
Audit report
The majority of evidence provided by the CSP by assessed by the
audit team using STAT. The results of the assessed requirements led to
the impression that some of the CSP security practices and mechanisms
are somewhat robust from operational and technical perspectives, while
certain areas must be reviewed and improved. Also, weaknesses were
identified in some cases that contradict the company’s requirements.
The areas of requirements identified to have achieved low and
nonconformance were thoroughly reviewed, prioritised and the audit
team proposed measure for their remediation. Hence, based on the
assessment undertaken, the audit team documented and delivered the
assessment report. The report contained a summary of findings on CSP
conformance level and a detailed list of remedial actions that must be
implemented by the CSP. It was communicated with the CSP, and they
provided an implementation plan outlining the duration it will take for
each remedial action to be affected.
7.4. Analysis of Feedback Results for STAF
This section presents an analysis of feedbacks collected from stake­
holders through the implementation of STAF. The focal point of the
analysis is to determine the validity of STAF in supporting organisations
to achieve security transparency from the stakeholders’ point of view.
The total number of responses received is highlighted in Fig. 10. Further,
the validity and acceptability results for STAF and STAT are analysed
based on the evaluation criteria (ease of use, relevance, usefulness,
flexibility and dynamics, compliance to security standards and best
practices, trustworthiness). The compiled results of responses from the
stakeholders’ according to the evaluation criteria are presented below in
Table 7.
An analysis of stakeholder feedback was conducted in accordance
with evaluation criteria derived from the renowned TAM model. The
analysis results have shown positive outcomes in terms of the stake­
holders’ overall perception regarding the acceptability of STAF. This
assertion is made because of the total positive responses obtained when
“Strongly Agree” and “Agree” are combined to determine the stake­
holders’ optimism on each of the evaluation criteria, as highlighted
below:
• Ease of use: 93.5% of the stakeholders considered STAF to be easy to
use.
• Relevance: 87% believed that STAF is relevant
• Usefulness: 93% believed that STAF is useful
• Flexibility: 80% considered STAF to be flexible
• Compliance with relevant Laws, Standards and Best Practices: 94%
believed STAF to be compliant
• Trustworthiness: 73% considered STAF to be trustworthy
Based on the overall summation of the feedback, as shown above, it
can be established that an average of 87% of the stakeholders have
accepted the proposed framework, while only about 13% views
expressed otherwise. In a positive sense, the stakeholders have
expressed enthusiasm and appreciation of STAF for representing good
coverage of their needs. They acknowledged that it had a positive impact
on the organisation’s security transparency aspirations.
7.5. Analysis of feedback results for STAT
The analysis result of stakeholders’ feedback regarding the effec­
tiveness and usability of STAT is presented. The analysis is carried out to
determine the validity, relevance, and acceptability of STAT’s features
in supporting the organisation achieve security transparency from a
technical perspective. Similarly, the analysis is performed according to
the evaluation criteria earlier mentioned, which include ease of use,
relevance, usefulness, flexibility and dynamics, compliance to security
standards and best practices, trustworthiness. In Table 8, a summary of

14
U.M. Ismail and S. Islam Journal of Information Security and Applications 54 (2020) 102594

Table 6
Threats profile and list of requirements.
Threat ID Threat Name Threat Category Target Threat Severity
Assets

S T R I D E D R E A D Severity
Rating

T01 Data breach * Company and customer data 3 2 3 2 3 High

T02 Weak identity, credential and Application and databases 2 3 3 2 3 High
access management
T03 Insecure APIs * * * * Frontend application 3 2 1 2 2 Medium
T04 System and application * * * * * * Application, database, 3 2 3 3 3 High
vulnerabilities company and customer data.
T06 Malicious insiders * * * Application, databases, 3 2 3 2 1 Medium
company and customer data.
T07 Advanced persistent threats * * All assets 3 1 1 3 1 Medium
(APIs)
T08 Data loss * * All data 2 2 1 2 1 Medium
T09 Insufficient due diligence * * * * * * All assets 3 3 2 2 1 Medium

T10 Abuse and nefarious use of * All assets 2 1 1 3 2 Medium

cloud services
T11 Denial of service * All assets 2 1 1 2 1 Low
T12 Shared technology * * All assets 1 2 2 1 1 Low
vulnerabilities
Requirement Control Domain Control Type Specification

Transparency Supply chain mgmt.,
transparency & accountability
Data quality CSP should work with their supply –chain partners to ensure data quality errors and
& Integrity associated risks are prevented. Providers should also design and implement controls to
mitigate and contain data security risks through adequate access controls, separation of
duties and least privilege access to all personnel within their supply chain.
Incident Information about security incidents that affected customers should be made available by
reporting the CSP through electronic methods such as portals.
Provider Internal security assessments should be performed at least annually to establish
Internal conformance and effectiveness of policies, procedures and supporting measures.
Assessments

Encryption & key mgmt.
Key Policies and procedures for managing cryptographic keys in the cloud service
generation cryptosystem must be established.
Storage and Appropriate platform and data encryption in v formats and standard algorithms should
access be implemented while making sure that keys are not stored in the cloud but maintained
by a trusted key management provider.

Business Business community mgmt. & Business Procedures and policies shall be established for a unified framework that documents and
operational resilience continuity ensures business continuity plans ensures business continuity plan are consistent in
planning addressing priorities for testing, maintenance and development according to the
organization’s requirements.
Business There should be planned testing of Implemented business continuity and security
continuity incident response plans on regular intervals or upon significant changes to CSP’s
testing environmental factors.
Resource Cloud resources should be sufficiently provisioned according to the organization’s
provisioning requirements.
Operational Threat and vulnerability Antivirus/ Technical measures, including policies and procedures, should be established to prevent
management malicious the execution of malware on organizationally-owned assets
software
Datacentre security Data centre Processes, procedures and controls should be implemented for ensuring physical security
security and parameters for safeguarding sensitive assets.
asset
management
Application & Interface Application The provisions and recommendations of industry standards should be followed in the
Security Security design, development, deployment and testing of applications and programming
interfaces (APIs)

stakeholders’ response is provided. An overall analysis result of stake­
holder’s perception about STAT is presented in Fig. 11.
The analysis of stakeholders’ feedback regarding STAT demonstrates
significant acceptance rating of the tool. By computing all positive re­
sponses i.e. “Strongly Agree” and “Agree”, the evaluation outcome has
revealed strong positive acceptability amongst stakeholders that have
used the tool.
• Ease of use: 87% perceived that STAT is relatively easy to use
• Relevance: 93% believed that STAT is relevant to the context
• Usefulness: 93% also considered STAT to be useful
• Flexibility: 80% believed that STAT is flexible
• Compliance with relevant Laws, Standards and Best Practices: 73%
of the stakeholders believe that STAT is compliant with relevant laws
and standards
• Trustworthiness: 67% perceived STAT to be trustworthy
An average of 82% of the stakeholders that evaluated STAT
expressed optimism regarding the acceptability, validity and usefulness
of STAT. This is a reasonable result that highlight the significance of
STAT to support the attainment of security transparency. The tool has
enabled the organisation to address the key issues related to security
transparency. In particular, the results have shown that STAT can be
used as an independent security transparency tool or as a supplementary
component to STAF.

15
U.M. Ismail and S. Islam Journal of Information Security and Applications 54 (2020) 102594

Fig. 11. Stakeholders view about STAT.

Fig. 9. Summary of overall conformance levels.
Fig. 10. Acceptability ratings of STAF according to six evaluation criteria.
concepts that constitute security transparency in cloud computing such
as actor, assets, risk management etc. The aim is to introduce high-level
elucidation of the foundation concepts that underpin transparency,
which is indeed valuable for helping organisations have a comprehen­
sive understanding of how cloud security transparency can be imple­
mented at from an organisational and technical perspective, thus
fulfilling RQ1. Furthermore, a process for STAF is proposed to support
RQ2. The process provides a structured set of activities that can be fol­
lowed by an organisation towards implementing the conceptual meta­
model. For RQ3, RQ4, and RQ5, STAT is developed to serve as a
supplementary component for the proposed framework, which provides
a simplified way for organizations to request for and obtain evidence
from CSPs, perform an assessment of collected evidence to determine the
conformance level to requirements and recommend remedial actions for
areas that need strengthening. Fulfilling these requirements is perceived
to be remarkable contributions that fill the knowledge gap in state-of-
the-art. In particular, it has addressed the limitations identified in pre­
vious approaches for enabling security transparency

Table 7 8.2. General findings

Responses for STAF.
Case Study Participating Stakeholders Participating Stakeholders General findings discuss the results of our work about supplementing
Senior Mgt. IT Personnel Senior Mgt. IT Personnel the security transparency framework that we have proposed [11]. To
Participants 5 13 4 12
contribute towards that, the process and tool proposed in this paper have
Total 18 16 created a bridge between the different levels of abstraction in our
framework, especially by providing a comprehensive process to guide
implementation and a supporting audit tool for probing CSP about the
Table 8
fulfilment of user requirements. Therefore, the implementation of the
Responses for STAT. tool and process have demonstrated a holistic approach that efficiently
connects highly-abstract organizational requirements to cost-effective
Case Study Participating Stakeholders Participating Stakeholders
auditing technique that provides crucial insight for establishing assur­
Senior Mgt. IT Personnel Senior Mgt. IT Personnel ance. The activities of STAF process are comprehensive, simple, and
Participants 2 15 2 13 direct, which neither an incurred financial burden nor significant human
Total 17 15 resources burden to the organisation. The features of the tool bolster the
auditors’ ability in assessing because it provides quality features that
facilitate the creation of an audit checklist, evaluation criteria and
8. Discussions
control actions.
During implementation and evaluation, we have observed limita­
The proposed STAF process presented in this paper has proven to be
tions. For example, a noticeable limitation is that STAT does not support
effective in addressing the security transparency issues of a studied
an automated assessment of evidence, which could be a resource and
context where concerns are related to gaining transparency on the. We
time-consuming. To address this limitation, we aim to incorporate an
summarize and discuss our findings by grouping our results into two:
intelligent assessment system that comprises different modules for evi­
general findings and applicability to security transparency scenarios.
dence assessment and supporting auditor’s judgement using subjective
logic. Another limitation to the implementation of STAF is the additional
8.1. How STAF requirements are met training required to perform the activities to avoid misconception and
misinterpretation of the steps. Specifically, most of the activities in the
In this section, we describe how the requirements for developing the framework, such as risk management, are mostly carried out manually
framework as outlined under the methodology have been achieved. The without the application of automated techniques. Hence, implementa­
paper provided a conceptual view that establishes and defines important tion of the framework it is necessary to train the users about the

16
U.M. Ismail and S. Islam
framework. We are planning to develop guidance and checklist for the
implementation.
8.3. Applicability to real-world scenario
The applicability to real-world scenario discusses how our work can
solve real-life problems. Findings of the implementation have shown the
quality of our work to be relevant and appropriate to a real-world
environment. Notably, both STAF has been validated for its usefulness
and validity in enabling and supporting businesses to achieve security
transparency, as well as the integration of activities that focus on se­
curity transparency within a cloud migration exercise. Further, STAT
was also evaluated for its usability and acceptability in supporting the
collection and analysis of evidence from CSPs and reporting of findings
for remedial actions. The stakeholders provided invaluable feedback on
their experiences and perception about the proposed framework and its
supporting tool, i.e. the analysis of participants’ feedback provided an
encouraging finding that shows the relevance, validity and acceptability
of the proposed framework amongst organisations. The participants
expressed optimism about our approach and its potentiality in
addressing the current and emerging security transparency issues in
cloud computing. This consideration implies a significant contribution
to the knowledge domain and state-of-the-art. In general, the case-study
contexts have benefited from using STAF and STAT respectively to
address a pressing concern of lack of transparency, as well as the chance
for adopting these solutions.
8.4. Comparison to existing works
In the previous Section 2, we have highlighted and categorized the
different state of the art literature according to security and controls in
clouds, security audit and assurance frameworks, software agent and
SLA monitoring, and industry practice and systems. In this section, we
provide a comparison so that readers would better understand the
similarities and uniqueness of our contribution to other works. The
literature on cloud digital forensics, software agent and SLA monitoring
follow a similar approach that involves a process for the collection and
processing of provenance data, audit trail data and violations to a spe­
cific metric. The heterogeneity of the cloud, the evidence that is
generated by different tools at different layers in the cloud, availability
and access to evidence is challenging to auditors especially due to the
privacy protection problems that originate from multitenancy, in addi­
tion to access to evidence sources and potentially different jurisdictions
with respect to globally operated cloud service. Our work is similar to
these approaches in that it also proposes the collection and analysis of
evidence that are not just specific to a particular layer, but also on
critical areas of focus in cloud security such as data governance and
operations management. This is done through a module within our tool
that enables the collection of specific evidence related to the require­
ment that is subject to verification. Furthermore, the industry best
practice initiative called CSA CAIQ has produced a set of assertion
questions that are designed to support cloud customers to ask about
CSPs operations and operations but does not support continuous probing
of such assertions based on verifiable evidence. The STAT proposed in
this paper is an improved version of performing evidence-based probing
of CSP assertions. The tool comprises evidence evaluation rules that
serve as the underlying structure for the development of criteria for
calculating CSP conformance to requirements, and evaluation rules and
results. The application of the rule and evidence-based analysis helps the
cloud user in making rational decisions and allowing appropriate
remedial actions to be implemented.
8.5. Future work
This research has unlocked the potentials for different research di­
rections and works in the area of cloud transparency. It is vital to outline
17
Journal of Information Security and Applications 54 (2020) 102594
the direction of future research and how some of the limitations
mentioned above can be addressed. One of the important future research
is the complete automation of the STAT to perform the intelligent audit
assessment, reporting, as remedial actions. Also, the automation will
cover the process, which will ensure that every activity is performed
with consistency and accuracy and reduce the chances of human error.
We believe that the automation process will improve reliability, thereby
leading to wider acceptability amongst businesses.
9. Conclusion
The lack of security transparency is becoming an increasingly
important concern for businesses who entrust their information assets
with a CSP. The significance of security transparency is expanding, even
more, every day as businesses are growingly concerned about the level
of visibility rendered by cloud services, which also adversely affect user
trust. There is a necessity for a viable solution that supports companies
to systematically have visibility into cloud activities, methodically track
and probe how salient requirements are being fulfilled. This paper
contributes towards this direction by proposing a comprehensive
framework and a tool to support the accomplishment of security trans­
parency, which potentially improve businesses trust in cloud services.
We have used a case study to demonstrate the usefulness of the frame­
work. The results based on the case study context and user feedback
show that it is a viable solution, effective and easy to use for achieving
cloud transparency. We believe that the proposed framework, its process
and supporting tool will have a significant impact in the cloud
computing domain and state-of-the-art in general.
Declaration of Competing Interest
None.
Supplementary materials
Supplementary material associated with this article can be found, in
the online version, at doi:10.1016/j.jisa.2020.102594.
References
[1] Chow R, et al. Controlling data in the cloud: outsourcing computation without
outsourcing control. In: Proceedings of the 2009 ACM workshop on Cloud
computing security. ACM; 2009.
[2] Rashidi A, Movahhedinia N. A model for user trust in cloud computing. Int J Cloud
Comput: Serv Architect (IJCCSA) 2012;2(2):1–8.
[3] Pauley W. Cloud provider transparency: an empirical evaluation. IEEE Security
Privacy 2010;8(6):32–9.
[4] Popović K, Hocenski Ž. Cloud computing security issues and challenges. In: MIPRO,
2010 proceedings of the 33rd international convention. IEEE; 2010.
[5] So K. Cloud computing security issues and challenges. Int J Comput Netw 2011;3
(5):247–55.
[6] Pearson S, Benameur A. Privacy, security and trust issues arising from cloud
computing. In: Cloud computing technology and science (CloudCom), 2010 IEEE
second international conference on. IEEE; 2010.
[7] Cloud Security Alliance. CSA STAR: the future of cloud trust and assurance. 2015
[cited 2015 04-09-2015]; Available from: https://cloudsecurityalliance.
org/star/#_overview.
[8] Davis FD, Bagozzi RP, Warshaw PR. User acceptance of computer technology: a
comparison of two theoretical models. Manage Sci 1989;35(8):982–1003.
[9] Davis FD. Perceived usefulness, perceived ease of use, and user acceptance of
information technology. MIS Q 1989:319–40.
[10] Salah K, et al. Using cloud computing to implement a security overlay network.
IEEE Security Privacy 2012;11(1):44–53.
[11] Al-Haidari F, Sqalli M, Salah K. Impact of cpu utilization thresholds and scaling size
on autoscaling cloud resources. In: in2013 IEEE 5th international conference on cloud
computing technology and science. IEEE; 2013.
[12] Calyam P, et al. VDC-Analyst: Design and verification of virtual desktop cloud
resource allocations. Comput Netw 2014;68:110–22.
[13] Rashvand HF, et al. Distributed security for multi-agent systems–review and
applications. IET Inf Security 2010;4(4):188–201.
[14] Khan MA, Salah K. IoT security: Review, blockchain solutions, and open
challenges. Future Gen Comput Syst 2018;82:395–411.
U.M. Ismail and S. Islam
[15] Cloud Security Alliance. Cloud Controls Matrix v3.0.1 (9-1-17 Update). 2017 [cited
2017 02/10/2017]; Available from: https://cloudsecurityalliance.org/download/
cloud-controls-matrix-v3-0-1/.
[16] Cloud Security Alliance. Consensus Assessments Initiative Questionnaire2017
[cited 2018 25/06/2018]; Available from: https://cloudsecurityalliance.org/down
load/consensus-assessments-initiative-questionnaire-v3-0-1/.
[17] Ouedraogo M, et al. Adopting an agent and event driven approach for enabling
mutual auditability and security transparency in cloud based services. In:
Proceedings of the international conference on cloud computing and services
science; 2015.
[18] Casola V, et al. Preliminary design of a platform-as-a-service to provide security in
cloud. In: Closer; 2014.
[19] IBM. IBM Security QRadar Version 7.3.2. 2017 [cited 2019; Available from:https
://www.ibm.com/support/knowledgecenter/SS42VS_7.3.2/com.ibm.qradar.do
c/b_qradar_users_guide.pdf.
[20] CloudWatch, A.Amazon CloudWatch: User Guide. 2019 [cited2019; Available from:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/acw-ug.
pdf.
[21] Succar B. Building information modelling framework: a research and delivery
foundation for industry stakeholders. Autom Constr 2009;18(3):357–75.
[22] Ismail UM, et al. A framework for security transparency in cloud computing. Future
Internet 2016;8(1):5.
[23] Knublauch H, et al. The Protégé OWL plugin: an open development environment for
semantic web applications. In: International semantic web conference. Springer;
2004.
[24] Swiderski F, Snyder W. Threat Modeling (Microsoft Professional), 7. Microsoft
Press; 2004.
[25] Shostack A. Experiences threat modeling at microsoft. In: Modeling security
workshop. dept. of computing. UK: Lancaster University; 2008.
[26] Höne K, Eloff JHP. Information security policy—what do international information
security standards say? Comput Security 2002;21(5):402–9.
18
Journal of Information Security and Applications 54 (2020) 102594
[27] Open Web Application Security Project. OWASP Risk Rating Methodology. 2014
[cited 2018 05/02/2018]; Available from: https://www.owasp.org/index.php/
OWASP_Risk_Rating_Methodology.
[28] OWASP Cloud - 10 Project. Cloud Top 10 Security risks2014 [cited 2018; Available
from: https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_1
0_Project.
[29] European Network and Information Security Agency. Cloud Computing Security
Risk Assessment. 2009 [cited 2017 05/08/2017]; Available from: https://www.eni
sa.europa.eu/publications/cloud-computing-risk-assessment.
[30] Centre for Internet Security. The Critical Security Controls for Effective Cyber
Defense. 2018 [cited 2018 18/05/2018]; Available from: file://dl-stud1/users/
d35/u0852138/Downloads/CIS%20Controls%20Version%207%20(1).pdf.
[31] ENISA. Technical Guidelines for the Implementation of Minimum Security
Measures for Digital Service Providers2016 [cited 2016 06/05/2018]; Available
from: file://dl-stud1/users/d35/u0852138/Downloads/WP2016%203-2%204%
20Technical%20guidelines%20for%20implementation%20of%20minimum%
20security%20measures%20(3).pdf.
[32] ISA, I.S.o.A. Handbook of International Quality Control, Auditing, Review, Other
Assurance and Related Services Pronouncements. 2016 [cite 11/02/2018];
Available from: https://www.kacr.cz/file/4133/2016-2017-iaasb-handbook-vol
ume-1.pdf.
[33] Venkatesh V, et al. User acceptance of information technology: Toward a unified
view. MIS Q 2003:425–78.
[34] Rashvand HF, Salah K, Calero JMA, Harn L. Distributed security for multi-agent
systems–review and applications. IET Inf Security 2010;4(4):188–201.
[35] Uzunov AV, Fernandez EB, Falkner K. Securing distributed systems using patterns:
a survey. Comput Security 2012;31(5):681–703.
[36] Fernandez EB, Larrondo-Petrie MM. Securing design patterns for distributed
systems. In: Security in distributed, grid, mobile, and pervasive computing.
Auerbach Publications; 2007. p. 67–80.