This article has been accepted for publication in IEEE Security and Privacy but has not yet

been fully edited.

Some content may change prior to final publication.

Page 1

Cloud Security Auditing:

Challenges and Emerging Approaches



Jungwoo Ryoo (jryoo@psu.edu),
Syed Rizvi (srizvi@psu.edu),
William Aiken (wva5029@psu.edu), and
John Kissell (jzk5354@psu.edu)

Penn State University

ABSTRACT


An Information Technology (IT) auditor collects information on an organization's
information systems, practices, and operations and critically analyzes the information for
improvement. One of the primary goals of an IT audit is to determine if the information system
and its maintainers are meeting both the legal expectations of protecting customer data and the
company standards of achieving financial successes against various security threats. These goals
are still relevant to the newly emerging cloud computing model of business, but with a need for
customization. We believe that there are clear differences between cloud and traditional IT
security auditing, which is validated by our interviews with cloud security auditors. Therefore,
this paper explores potential challenges unique to cloud security auditing. The paper also
examines additional challenges specific to particular cloud computing domains such as banking,
medical, and government sectors. Finally, we present emerging cloud-specific security auditing
approaches and provide our critical analysis.


  
 
  
 
  



INTRODUCTION


Cloud computing, as defined by the National Institute of Standards and Technology
(NIST) in Special Publication 800-145, is “a model for enabling ubiquitous, convenient, on-
demand network access to a shared pool of configurable computing resources (e.g., networks,
servers, storage, applications, and services) that can be rapidly provisioned and released with
minimal management effort or service provider interaction” (Mell, 2011). In essence, cloud
computing could simply be described as the use of computing resources, both hardware and
software, which are provided over a network, and it also requires minimal interaction between
users and providers. NIST goes even further to list what are deemed as five "essential
characteristics" which are used for the composition of a cloud model; these five characteristics,

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 2

in no particular order, are: on-demand self-service, broad network access, resource pooling, rapid
elasticity, and measured service (Mell, 2011).
There are primarily three service models (or service types) which are commonly
implemented in the cloud: Software as a Service (SaaS), Platform as a Service (Paas), and
Infrastructure as a Service (IaaS). Regardless of the service types, one of the most significant
challenges in cloud computing is security and oversight to enhance security. Audits provide a
clear and recognizable trail of resource access for both companies and governments. Typically,
audits will fall into two main categories, internal and external audits, and we will be using this
dichotomy of audits throughout the paper. Internal audits refer to work done by employees of the
company, which concern themselves with very specific processes within the company, primarily
focusing on optimization and risk management, while external audits refer to audits that give an
outside perspective on the company’s ability to meet the requirements of various laws and
regulations. Organizations have used traditional IT audits to evaluate issues such as availability
to authorized users, and integrity and confidentiality in the storage and transmission of data.
Cloud audits must be able to meet these same standards in the context of cloud computing.

Do traditional IT security audit models meet the needs of cloud systems? What happens if the
information system is completely overhauled, if all of an organization’s IT resources are put in
the hands of someone else (i.e., in the cloud)? By definition, cloud computing allows an
organization to perform the necessary computer tasks on remote servers via a network
connection while passing off the complex tasks of actual networking to a third party. Since cloud
computing allows for multiple users across a large domain, it is exposed to novel security threats.
These threats range from the confidentiality threats when two different businesses have their data
stored together (i.e., colocation due to multi-tenancy) to encryption concerns in both the home
and cloud companies (such as who keeps the encryption keys). These new threats pose new
challenges for security auditing, but cloud advocates are responding to them. Already there are
groups such as Cloud Security Alliance (CSA: cloudsecurityalliance.org) urging for
standardizing the practice of auditing cloud confidentiality, integrity, and availability.

In this research paper, our primary research goal is to highlight the essential challenges
that separate cloud security auditing from the traditional IT security auditing practices. These
challenges mark the distinction between the two auditing approaches and highlight the
importance of special provisions for cloud security auditing in the existing security auditing
standards. Although security audits on cloud computing and those on traditional IT have similar
goals and objectives, the details of how they are evaluated, such as scope, emphasis, depth, etc.,
divide the audits into two very distinct processes.
In addition to the differences between the cloud and conventional IT security auditing,
the specifics of cloud security auditing can vary depending on what domain the cloud is used for.
These domains include medical, banking, and government sectors, and we identify the subtle
differences that require somewhat different approaches despite the largely common body of the
core cloud security auditing methodology.
We also investigate the cutting edge of standards being used by the cloud industry to
have a consistent line of defense against these security threats in the Emerging Approaches

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 3

section. To validate our research, we conducted a series of interviews with experienced cloud
security auditors and incorporated their insights and advice into the discussions in the following
sections. Some new ideas from the perspective of practitioners have also emerged from our
discussions with the auditors.


CHALLENGES


A traditional IT security audit is an examination of the checks, balances, and controls
within an IT group. An IT security audit collects, evaluates, and tests information on an
organization's systems, practices, and operations, and it determines if the systems are
safeguarding the information assets, maintaining data integrity, and operating effectively to
achieve the organization's business goals or objectives (Cannon, 2011). Therefore, IT security
auditing needs to analyze the data from internal and external sources to support audit objectives
accurately.
The cloud computing field is a flourishing industry that comes with its own set of new
security challenges. A cloud infrastructure is the result of a constant three-way negotiation
among service organizations, cloud service providers (CSPs), and end users to ensure
productivity while maintaining a reasonable degree of security. The CSP should keep data safe
from security threats and yet give the client access anywhere with an Internet service. A client
organization also needs to verify that the cloud computing enterprise is contributing to its
business goals and objectives, and future needs.
Although both conventional IT security auditing and cloud security auditing share many
common concerns, a security audit of the cloud system has to consider and address unique
problems typically not handled in the traditional IT security audits.
According to our interviews, the most immediate and obvious challenge lies in acquiring
sufficient knowledge in cloud computing for an auditor to know what additional items to audit in
order to address cloud-specific security concerns. Therefore, to function as an effective cloud
security auditor, familiarity with cloud computing terminology and working knowledge of what
constitutes a cloud system and how cloud services are delivered are essential. This knowledge
then enables a cloud security auditor to pay special attention to a set of security factors that may
be emphasized much less in a traditional IT security auditing process. These factors include
transparency, encryption, colocation, scale, scope, and complexity concerns which are discussed
in detail in the following subsections and summarized in  
.


Transparency


An audit must check whether a CSP keeps security-relevant data transparent to its
customers. Transparency allows an organization to more easily identify potential security risks
and threats and also create and develop the right countermeasures and recommendations for its

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 4

enterprise (Pauley, 2010). By having access to accurate information, a cloud service user (CSU)
can reduce the risk of threats being manifested.
A good cloud security audit would question if the CSP provides a solid balance between
security procedures and end-user access. Employees may need to access the cloud from home or
on a business trip. Does the CSP allow for such types of access, and can it prevent others from
impersonating legitimate users? More importantly, is the CSP willingly transparent about its
access control mechanisms?
Typically, cloud computing systems are based in a large data center, and a third party
subcontractor could be managing them. The client has no idea who handles the data or where
exactly on the system it is stored. To expose the risks associated with this undesirable situation, a
cloud security audit must strive to reveal the details to the client. Transparency of data privacy,
data security, anonymity, telecommunications capacity, liability, reliability, and government
surveillance ensures strong security on the client’s data (Pauley, 2010). For example, a CSP that
records personal information such as credit card numbers is an invitation for cyber criminals. As
a result, a service-oriented company that utilizes a third-party cloud infrastructure or any CSUs
should expect to know what kind of information is in the cloud at any given time to adequately
respond to breaches.
A lack of data transparency even in traditional IT audits can lead to a failure of control
over in-house company resources. Systems administrators should not be the only ones to
adequately understand the computing resources and the risks associated with them.
A traditional IT security audit gathers and analyzes the data found on the company
premises. Without this type of audit, a company has no idea what its assets are, where they are
stored, or how to protect them from any potential threats. A company’s security is theoretically
non-existent without these audits. Asset enumeration (or identification) refers to this type of
auditing efforts. Why should the cloud be any different in terms of data transparency? In fact,
transparency is even more critical in cloud security auditing because the security-relevant data is
harder to obtain since CSPs control most of the data rather than CSUs. A company-wide
understanding (not just by the IT department) of asset data, data location, and data policies is
necessary to any cloud security audits as well. In terms of data transparency, cloud security
audits require the same degree of understanding as do their traditional IT security audit
counterparts, but an insufficient amount data often exists to develop the same level of
understanding.


Encryption


It is unsafe to store plaintext data anywhere, especially outside of the home company IT
infrastructure. If the cloud were to be breached, the information would be instantly available to
the hackers. A client could encrypt all of the data in-house before sending it to the cloud
provider, but this approach opens risks to system administrators who may abuse their privileges.
Leaving encryption to the CSP is not foolproof either because a breach in its storage system may

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 5

also mean a breach in its encryption and decryption tools. In reality, CSPs frequently provide the
encryption service by default as in the case of Amazon Simple Storage Service (S3), which could
result in double encryption (once by a CSU and twice by a CSP). In contrast, the Amazon elastic
computer cloud (EC2) service does not provide encryption by default, leaving it up to the
customers. There is also a third party service available, such as ciphercloud.com that provides its
client with an ability to encrypt the data before sending it to a CSP.
Traditional IT infrastructures face many encryption concerns as well and must make
tough decisions. Which is more important: encryption of data or access to data? If an entire data
pool is encrypted at rest, how can an organization quickly and efficiently query the data without
decrypting all of it? Due to its heavy computational requirements, encryption may not always be
the most efficient solution. Only in situations where the sensitive data is not accessed frequently
(e.g., archived payroll information), does encryption at rest become a viable option for traditional
IT companies.
A cloud infrastructure is not free from these pitfalls, either. The same question arises
again: should data at rest be encrypted? The difference is that an organization does not send
plaintext data to the cloud. The data in transmission is usually encrypted, using technologies like
Secure Socket Layer (SSL) as in the Amazon S3 services. Assuming that a CSU depends solely
on the CSP for encryption, the CSU organization must allow the CSP to control its
encryption/decryption mechanisms and have access to all the data it stores (e.g., Amazon S3).
This is not a safe practice because if one part of the cloud should be compromised, it is
possible that all encrypted data will be compromised as well. As a result, it is more desirable for
encryption and decryption to take place outside the cloud’s resources. But is encrypting and
decrypting cloud storage data worth the extra computational resources? Possibly, but newer
innovations in fully-homomorphic encryption allow encrypted queries to search encrypted texts
without search engine decryption. This type of encryption holds a potential to solve the issue of
encrypted data at rest in both traditional IT and cloud infrastructures.
According to the auditors we interviewed, in a traditional IT security audit, both external
auditors and an audited company meet on the audited company’s premises and strive to reach a
balance of privacy between them: the auditors want to keep the queries secret, and the audited
company wants to preserve the privacy of all its encrypted data. The auditor is given access to
necessary data within the audited company just enough to complete the work. The auditors have
access but may not copy or remove anything from the company. In this way, they reach a
balance of privacy.
The struggle to obtain a balance of privacy also occurs in various cloud computing
scenarios. In a cloud system, however, such collaboration between the audited company and the
auditors may not be nearly as efficient, possible, or necessary because all the data resides within
a third party infrastructure (i.e., the CSP’s datacenters). The CSP may not be willing or able to
disclose certain cryptographic information, even under auditing circumstances. To help mitigate
this cloud-specific problem, the payment card industry-data security standard (PCI-DSS) cloud
special interest group (SIG) strongly encourages that cryptographic keys and encryption

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 6

algorithm information “be stored and managed independently from the cloud service” (Cloud
Special Interest Group PCI Security Standards Council, 2013).


Colocation


The core principle and benefit of cloud computing is the idea that multiple user
organizations can share the physical systems of one service organization. Although a great
method of reducing cost, sharing the technology infrastructure leads to equally great security
concerns. It is crucial to a CSP that it keeps any user system from gaining any administrative
access to the physical hardware to prevent the abuse of services or access to other clients’ data.
The most common cloud service that encounters this problem is Infrastructure as a
Service (IaaS), and to handle these problems, a CSP turns to a hypervisor that insulates virtual
machines (VMs) from the physical computing hardware. Two primary examples of hypervisors
in use today are Xen Hypervisor (open source) and VMWare (proprietary). Also competing in
the hypervisor market are Microsoft’s Virtual Server, the Kernel-based Virtual Machine (KVM),
IBM’s PowerVM, and many others that include Intel and AMD’s own architectures. The security
auditing problem arises from this situation: there are countless ways to organize or establish a
hypervisor in a cloud system, each with its own strengths and weaknesses, and priorities.
A CSP must not only balance the business needs of a hypervisor and/or colocation system
but also the security issues. Despite the apparent need to standardize the structure and security of
colocation, no official standard exists. Even PCI does not list specialized standards regarding the
evolving colocation concerns. However, the PCI Cloud SIG has developed a few
recommendations for multi-tenancy (Cloud SIG PCI-DSS Council, 2013).
For example, they provide three sample cloud environments of what they consider proper
cloud segmentation environments: 1) traditional separate servers for each client’s cardholder data
2) virtualized servers dedicated to each client and its cardholder data, and 3) applications run in
separate logical partitions and separate database management images with no sharing of
resources like disk storage.
Considering the multitude of cloud/hypervisor combinations and varying degrees of
cloud adoption, a PCI-DSS-style evaluation of a cloud system will have to be done on an
individual basis. To assert the importance of proper colocation security, the PCI Cloud SIG
issued this statement regarding multi-tenancy: “Without adequate segmentation, all clients of the
shared infrastructure, as well as the CSP, would need to be verified as being PCI-DSS-compliant
in order for any one client to be assured of the compliance of the environment.”

Scale, Scope, and Complexity

In cloud computing, one physical machine typically hosts a number of VMs, which
drastically increases the number of machines to be audited. Unless carefully managed, the sheer
number of these VMs could be overwhelming to both IT staffs and auditors. However when

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 7

standardization is in place (e.g., in the form of master hard drive images verified for security),
the auditing process can go smoother and faster despite the larger scale nature of cloud
computing elements.
Another factor to consider is the scope of auditing. While the scale problem results from
the increased number of identical or similar IT elements to audit, the scope factor emerges
mainly due to the new types of technologies to audit in cloud computing. For example,
examining the security of hypervisors is much more important when dealing with CSPs because
of the colocation problem mentioned in the previous section. If hypervisors have a vulnerability
that breaches the strict separation between VMs, CSUs will be very uncomfortable with the idea
of having their VMs side by side with VMs belonging to other organizations including their
competitors. In addition, there are also many intangible and logical elements to audit in a cloud
environment, which include virtual switches, virtual firewalls, etc. Therefore, auditors need to be
aware of both subtle and obvious differences in the cloud-specific technologies that could
threaten the security of CSUs.
Due to the increase in both scale and scope, the complexity of the systems to be audited
in general also increases. As a result, a competent cloud auditor should take into account this
complexity cloud security auditing presents. Special considerations should be made when
planning a cloud security audit by allocating more time and resources than in a traditional IT
auditing process.
The complexity problem becomes even worse because cloud computing makes it possible
to store an organization’s data and information at data centers operated by a CSP across multiple
countries. These countries apply varying laws and regulations. This means that the compliance
requirements for the client organization to consider are no longer bound to the physical location
of the CSU, which is why it is so crucial for a cloud security auditor to find out where the CSU’s
data and information are stored by the CSP. Colocation due to multi-tenancy also contributes to
the importance of the physical data and information storage location.

Type of Challenge Traditional IT Security Cloud-Specific Potential Cloud Security

Auditing Practice Challenge Auditing Solution
Transparency Data and Information Data and
Service Level Agreements
Security Management security are
(SLAs) should outline
Systems (ISMS) are more managed by aCSP policies and
accessible. third party.assurances while CSP
provides clients with audit
results.
Encryption Data owner has the CSPs may be Audit key holders and
control. responsible for encryption methods.
encryption.
Colocation This rarely occurs. CSPs heavily Standardization and more

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 8

depend on this. oversight

Scale, Scope, and They are relatively less. Auditors must Continuing education and
Complexity be new certification programs
knowledgeable
and aware of
these
differences.




   
 
  

DOMAIN-SPECIFICITY TO CONSIDER


Cloud computing offers a large umbrella of services that can be accessed anywhere.
Therefore, certain fields of business in different domains will have specific needs and variations
that could overwhelm a universal audit. Data types can also vary between domains, and so can
the legal requirements mandated for keeping that data safe. As a consequence, one-size-fits-all
audit may not ever satisfy all the various needs that a specialized audit should. Domain-tailored
audits, therefore, become an ideal solution.


Medical


Hospitals, doctors’ offices, and medical specialists are beginning to use various cloud-
based software applications that allow the sharing of patient information with other healthcare
professionals. The medical domain holds highly sensitive and confidential information, but it
needs to allow access by auditors, patients, pharmacies, and other institutions such as hospitals.
A sophisticated authentication method is especially essential to the medical cloud, both legally
and ethically. Any breach could result in an extreme loss to both the medical organization and
the patients.
Legally, the medical domain is held to a very high standard, facing large compensatory as
well as punitive costs in the case of a breach. Several legal standards exist to protect patients and
to regulate health care organizations. Some examples include:


HIPAA (Health Insurance Portability and Accountability Act)
HITECH (Health Information Technology for Economic and Clinical Health Act)
FDAAA (Food and Drug Administration Amendments Act)
ARRA (American Recovery and Reinvestment Act of 2009)


Consequently, the medical domain requires its own, specifically-tailored audit approach
to comply with these legal standards. A medical-domain cloud security audit would have to
deeply evaluate both the medical organization and the cloud containing its information.

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 9

CipherCloud describes itself as an organization dedicated to allowing organizations “to

enjoy the benefits of the cloud, which otherwise wouldn't be able to due to concerns about data
security, privacy, residency, and regulatory compliance” (CipherCloud, 2012). CipherCloud
recently announced that Medical Audit & Review Solutions (MARS) has taken advantage of
CipherCloud’s encryption infrastructure to create a hybrid “MARS PROBE Platform”
(CipherCloud, 2012). This as an example demonstrates the need for cooperation among different
organizations to tackle the demands of cloud security auditing in the medical domain. The
medical auditing system MARS incorporated the encryption strategy of CipherCloud, thus
forming a more comprehensive and secure auditing approach. The MARS PROBE Platform
itself is cloud-based, and it may prove to have the power to effectively audit medical
organizations and satisfy the demands of both HIPAA and HITECH. Similar hybrids in cloud
security auditing may be expected in the near future.

Banking


Banks have much more user-based traffic related to accessing online banking services
from various devices such as tablets, smartphones, public Wi-Fi hotspots, etc. Not only do they
have information incessantly being updated around the clock, but this information must also be
kept secure and available to all the clients who wish to access it. Yet despite the apparently
daunting task of constantly updating and securing sensitive data, banking in the cloud still holds
a great potential. TEMENOS Online, for example, has the goal of eliminating large overhead
expenses for small banking institutions, which in turn results in lower interest rates (TEMENOS
Online, 2011).
Although perfect security is impossible, the security systems and their audits must be able
to resist breaches and also respond to them, especially when billions of dollars and numerous
bank accounts are at risk. One of the biggest problems facing a relatively large banking cloud is
ensuring that the clients’ information cannot be stolen and/or sold. In our opinion, the safeguards
to this are twofold. First, all data stored in the cloud should be encrypted. Second, access to it
should be limited by permissions set by the online banking client. A traditional IT audit of a bank
that stores its data locally (or at that bank’s specific headquarters) usually does not need to worry
about other banks reaching the data, but if the infrastructure resembles that of TEMENOS, then
multiple banking institutions will use the same cloud infrastructure. The benefit is cost reduction
and the sharing of information between banks if the client has multiple accounts. The risk is that
a security breach with one bank may result in the breach of accounts with other banks as well as
the possibility of unintended access to banking data by competitors.


Government


The government is also entering the cloud domain (U.S. General Services Administration,
2012). Maintaining security and auditing of the CSPs are even more important in the government

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 10

sector due to the sensitive nature of data and information it deals with. For the authentication,
authorization, and auditing of the CSPs, government agencies must turn to Federal Risk and
Authorization Management Program (FedRAMP: U.S. General Services Administration, 2012).
As listed by the U.S. General Services Administration website, auditing is defined as the ongoing
assessment and authorization of the cloud providers (U.S. General Services Administration, 2012).
The three key areas listed on their website are Operation Visibility, Change Control
Process, and Incident Response. Operation Visibility requires that the CSPs submit automated
data feeds to the agencies along with periodically submitted evidence of the system performance
and the annual reports. Change Control Process restricts the CSP’s ability to make policy
changes that may possibly affect the FedRAMP requirements. Finally, Incident Response deals
with new possible risks or vulnerabilities in the cloud system as well as protecting government
information against leaks in the event of a breach.


EMERGING APPROACHES


Both cloud computing and traditional IT security audits must conform to some form of
standard, to be effective, and this aspect is where cloud computing finds its biggest potential to
growth in our opinion. Unlike traditional IT security audits, cloud computing security audits do
not have any complete and comprehensive certifications to cover their vast number of concerns.
Therefore, a cloud security audit often calls on a traditional IT security audit standard to make its
evaluation.
Based on our interviews with professional cloud security auditors, regarding the
standardization of cloud security auditing, there appear to be primarily three schools of thought.
One is a belief that we do not need a new standard at all. Since most of the traditional IT auditing
standards are technology-neutral by design, the existing standards are still relevant. It is the
responsibility of the auditors to develop their expertise in cloud computing and gain insights by
simply doing it. The other school of thought is to still keep the technology-neutral nature of the
well-known IT security auditing standards but to provide a supplement to the standards, which
contains cloud-specific information on what to especially look for or what to avoid in terms of
pitfalls when conducting a typical cloud security audit. Another way of thinking is to develop an
entirely new standard dedicated to cloud security auditing. The supplement approach is a great
compromise between no special consideration of cloud domain specificity and a dedicated, full-
blown cloud security auditing standard in our opinion.

One of the most widely used IT security auditing standards is the ISO 27000 series. The
ISO 27001 and ISO 27002 auditing standards have a long-standing history as ISO 27002 dates
back to a document published by the English Government in 1995 (The ISO 27000 Directory,
2009). The ISO 27000 official website lists the current audit standards, whose coverage varies
from internal audits to management responsibility, from security policy to physical security,
from access controls to compliance, and many other pertinent aspects of IT. For a traditional IT

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 11

audit, these kinds of controls fit well as all these concerns exist in-house, or rather, inside the
organization itself.
However, the issue arises when not all of these aspects can be handled within the same
organization. Therefore, for an organization in the cloud, ISO 27001/2 can only provide limited
support. As discussed earlier, in this case, the quality of an audit heavily depends on the
experience and knowledge of the auditor in cloud computing, which could be problematic. For
example, the encryption section of ISO 27000 series simply states that “a policy on the use of
cryptographic controls for protection of information shall be developed and implemented” and
that “key management shall be in place to support the organization's use of cryptographic
techniques” (International Organization for Standardization, 2005). There is no mention of the
different encryption scenarios for cloud auditors to understand to do their job effectively. The
same is true for other critical factors for cloud security auditing, such as transparency,
colocation, scale, scope, complexity, etc. since many of these problems arose after the drafting of
ISO 27001/2.
Unlike the technology-neutral approach of the ISO 27000 series, PCI-DSS has the
Qualified Security Assessor Cloud supplement to guide the cloud security auditors handling PCI-
DSS certifications in the cloud computing domain. In terms of organizations preparing to tackle
directly these various issues which are a product of cloud security auditing, the non-profit CSA is
using best practices to educate and help secure the many forms of cloud computing (Cloud
Security Alliance, 2013). Because the CSA is a non-profit, independent organization, it is able to
contribute to various cloud security groups. Moreover, the CSA has come to encompass other
smaller cloud interest groups. One such member group is CloudAudit, and according to its
official website, the organization lists its goals as an Automated Audit, Assertion, Assessment,
and Assurance of the cloud system while being “simple, lightweight, and easy to implement” and
being supported entirely by volunteer effort (CloudAudit, 2010). The CSA and its member
groups are not tied to any specific organization or standard, meaning that it is free to cover all
aspects of cloud computing in the forms of SaaS, PaaS, IaaS, and many more services.
Moreover, this system based on volunteer effort is reminiscent of the origins of the Internet
Engineering Task Force (IETF, 2013), one of the most important protocol-creating organizations
in the realm of computer networking.
Table 2 summarizes a wide spectrum of standards in terms of their coverage of cloud
security auditing. Although not specifically mentioned, Service Organization Control (SOC) 2
and NIST 800-53 Rev. 3 are similar to the ISO 27000 series in that they do not have any built-in
cloud-specific provisions in their standards.

Standard Type Strength Sponsoring

Organization
SOC 2 Audit for outsourced Technology-neutral AICPA (2012, 2013)
services
ISO 27001 & 27002 Traditional Security Audit Technology-neutral ISO (2005)

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 12

NIST 800-53 Rev. 3 Federal Government Audit Technology-neutral NIST (2005)

Cloud Security Alliance Cloud-specific Audit Dedicated to cloud N/A
security auditing
PCI-DSS PCI Qualified Security Technology-neutral but PCI-DSS (2013)
Assessor Cloud supplement still providing guidance


  
 


 
 

CONCLUSION & FUTURE DIRECTIONS

This paper explored various challenges unique to cloud security auditing. We also
discussed additional challenges specific to particular cloud computing domains such as banking,
medical, and government sectors. Some of the challenges we pointed out are technical (e.g.,
colocation and encryption) while others are more organizational in nature (e.g., transparency). A
capable cloud security auditor should be able to skillfully navigate through all these various
challenges to accomplish a successful audit. However, it takes years of experience to acquire the
skills, knowledge, and insights necessary to become a competent cloud security auditor.
This paper mainly focused on identifying the problems (i.e., challenges) associated with
cloud security auditing and introducing the existing resources to the traditional IT security
auditors faced with cloud security auditing tasks so that they could relatively quickly adopt the
resources for work at hand. There are several emerging solutions to these challenges in the form
of supplements in standards, regulations, new technologies, etc. Many of these resources or
solutions are still under development and not ready for full adoption yet.
Our future research will be more focused on improving each of the existing cloud
security auditing approaches discussed in this paper. Another future research goal is to identify
more challenges that clearly differentiate cloud security auditing from traditional IT security
auditing by conducting a full-blown, formal survey interviewing various stakeholders in the
cloud security auditing community. The more comprehensive the list of the cloud security
auditing challenges is, the better the beginning cloud security auditors will know what to look
out for when conducting their audits and therefore be able to produce more thorough and reliable
audit results.

ACKNOWLEDGEMENT
We consulted many cloud security practitioners while working on this article. In particular, we
would like to acknowledge the help and advice provided by Douglas Barbin, Principal
(Shareholder) at BrightLine CPAs & Associates, Inc. and Robert Sweeney, Internal IT Auditor at
the Hershey Company. Their insights were indispensable in completing this article.

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 13

REFERENCES
American Institute of CPAs (AICPA). (2012). Reporting on Controls at Service Organization Relevant to Security,
Availability, Processing Integrity, Confidentiality, or Privacy (SOC 2) – AICPA Guide. January 2012.

American Institute of CPAs (AICPA). (2013). Service Organization Control (SOC) Reports. Retrieved from
http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/pages/sorhome.aspx

Cannon, David. (2011). Certified Information Systems Auditor Study Guide. Third edition, Wiley Publishing, Inc.

CipherCloud. (2012, May 16). Ciphercloud enables healthcare pioneer to deliver a medical audit solution.

Retrieved from http://www.ciphercloud.com/Company/PressReleases/tabid/ 106/NewsId/15/CipherCloud-

Enables-Healthcare-Pioneer-to-Deliver-a-Medical-Audit-Solution.aspx

CloudAudit. (2010, February 12). CloudAudit: Automated audit, assertion, assessment, and assurance. Retrieved
from http://cloudaudit.org/CloudAudit/About.html

Cloud Security Alliance. (2013). About. CSA: Cloud Security Alliance. Retrieved from
https://cloudsecurityalliance.org/about/

Cloud Special Interest Group PCI Security Standards Council. (2013). Information Supplement: PCI DSS Cloud
Computing Guidelines. Retrieved from
https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Cloud_Guidelines.pdf

International Organization for Standardization (ISO). (2005). ISO/IEC 27001:2005, A. 12.3.2.

The Internet Engineering Task Force (IETF). (2013). Retrieved from http://www.ietf.org/

The ISO 27000 Directory. An introduction to ISO 27001, ISO 27002, and ISO 27008. (2009).
Retrieved from www.27000.org

Mell, Peter and Grance, Timothy. (2011). The NIST Definition of Cloud Computing.
Special Publication 800-145. Retrieved from
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

National Institute of Standards and Technology (NIST). (2009). Recommended Security Controls for Federal

Information Systems and Organizations. NIST Special Publication 800-53 Revision 3 Retrieved from

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf

Pauley, Wayne A. (2010). Cloud Provider Transparency: an Empirical Evaluation. IEEE Security and Privacy.
November/December 2010.

TEMENOS Online: Banking in the cloud. (2011). Retrieved from

http://www.temenos.com/temenos-online/banking-in-the-cloud/

U.S. General Services Administration. (2012, Nov. 20). FedRAMP: Ensuring secure cloud computing for the federal

government. Retrieved from http://www.gsa.gov/portal/category/102371

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 14

Jungwoo Ryoo is an associate professor of Information Sciences and Technology (IST) at the
Pennsylvania State University-Altoona. Dr. Ryoo is also a graduate/affiliated faculty member of
the college of IST at Penn State. He is a technical editor for the IEEE Communications
Magazine and working with IEEE and Software Engineering Institute (SEI) as a consultant. His
research interests include information assurance and security, software engineering,
and computer networking. He is the author of numerous academic articles and conducts
extensive research in software security, network/cyber security, security management
(particularly in the government and medical sector), software architectures, architecture
description languages (ADLs), object-oriented software development, formal methods and
requirements engineering. Many of Dr. Ryoo's research projects have been funded by both state
and federal government agencies. He also has substantial industry experience in architecting and
implementing secure, high-performance software for large-scale network management systems.
He received his Ph.D. in Computer Science from the University of Kansas in 2005 and a member
of both IEEE and ACM.
Postal address: 147 LRC 3000 Ivyside Park Altoona, PA 16601; E-mail: jryoo@psu.edu; Phone:
814-949-5243; Fax: 814-949-5456
Syed Rizvi is an Assistant Professor in the College of Information Sciences and Technology at
Pennsylvania State University. He received his doctorate in Modeling and Simulation from the
University of Bridgeport in 2010. His research interests lie at the intersection of computer
networking, network security and modeling and simulation. Recently, he has been working on
security issues in cloud computing, cognitive radios for wireless communications, and modeling
and simulation of large-scale networks. He has authored and coauthored over 80 technical
refereed and non-refereed papers in various conferences, international journal articles, and book
chapters in research and pedagogical techniques. He is a member of IEEE Communications
Society and ACM.

Postal address: 145 LRC 3000 Ivyside Park Altoona, PA 16601; E-mail: srizvi@psu.edu; Phone:
814-949-5292; Fax: 814-949-5456

William Aiken is a junior at Pennsylvania State University, majoring in Security and Risk
Analysis under the Information and Cyber Security Option with an emphasis on the auditing of
information systems. His primary research interest is ISMS auditing particularly in Cloud
Computing. He plans to continue to work in and improve his knowledge of the areas of
Information Technology where the technical aspects meet legal and regulatory compliance
standards. He is a member of the Schreyer Honors College at Penn State, an avid glossophile,
and aspiring information systems auditor. William can be contacted at wva5029@psu.edu.
Postal address: 1012 N 6th Ave Altoona, PA 16601; E-mail: wva5029@psu.edu; Phone: 814-
935-0890

John Kissell is a junior-standing student majoring in Security and Risk Analysis: Information

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE

 This article has been accepted for publication in IEEE Security and Privacy but has not yet been fully edited.
Some content may change prior to final publication.

Page 15

and Cyber Security with a minor in Information Sciences and Technology at the Pennsylvania
State University, and he is a member of the Schreyer Honors College at Penn State. His primary
research interests currently include Cloud Computing, with a special emphasis on security and
issues with legal and regulatory compliance. John can be contacted at jzk5354@psu.edu.

Postal address: 211 Coleridge Ave Altoona, PA 16602; E-mail: jzk5354@psu.edu; Phone: 814-
935-8242

Digital Object Indentifier 10.1109/MSP.2013.132 1540-7993/$26.00 2013 IEEE