Download - Cloud Security Auditing: Challenges and Emerging Approaches

Cloud Security Auditing:Challenges and Emerging Approaches

Jungwoo Ryoo ([email protected]), Syed Rizvi ([email protected]),

William Aiken ([email protected]), and John Kissell ([email protected])

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.

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



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



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



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



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



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 Auditing Practice

Cloud-Specific Challenge

Potential Cloud Security Auditing Solution

Transparency Data and Information Security Management Systems (ISMS) are more accessible.

Data and security are managed by a third party.

Service Level Agreements (SLAs) should outline CSP policies and assurances while CSP provides clients with audit results.

Encryption Data owner has the control.

CSPs may be responsible for encryption.

Audit key holders and encryption methods.

Colocation This rarely occurs. CSPs heavily Standardization and more



depend on this. oversight Scale, Scope, and Complexity

They are relatively less. Auditors must be knowledgeable and aware of these differences.

Continuing education and new certification programs

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.



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



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



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 services

Technology-neutral AICPA (2012, 2013)

ISO 27001 & 27002 Traditional Security Audit Technology-neutral ISO (2005)



NIST 800-53 Rev. 3 Federal Government Audit Technology-neutral NIST (2005) Cloud Security Alliance Cloud-specific Audit Dedicated to cloud

security auditing N/A

PCI-DSS PCI Qualified Security Assessor Cloud supplement

Technology-neutral but still providing guidance

PCI-DSS (2013)

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.



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



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: [email protected]; 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: [email protected]; 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 [email protected].

Postal address: 1012 N 6th Ave Altoona, PA 16601; E-mail: [email protected]; Phone: 814-935-0890 John Kissell is a junior-standing student majoring in Security and Risk Analysis: Information



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 [email protected]. Postal address: 211 Coleridge Ave Altoona, PA 16602; E-mail: [email protected]; Phone: 814-935-8242



Download - Cloud Security Auditing: Challenges and Emerging Approaches

Top Related