A survey of compliance issues in cloud computing

Abstract

Features such as elasticity, scalability, universal access, low entry cost, and flexible billing motivate consumers to migrate their core businesses to the cloud. However, in doing so there are challenges about security, privacy, and compliance. Businesses are pressured to comply with regulations depending on their service types; for example, in the US government agencies are required to comply with FISMA, healthcare organizations are required to comply with HIPAA; public retail companies must to comply with SOX and PCI. We survey work on compliance issues and we conclude that the lack of reference architectures and relevant patterns makes compliance harder than it should be. We also explore current industrial trends of compliance approaches. We end by summarizing compliance issues and give some guidelines about what this architecture and its corresponding patterns should contain.

1 Introduction

In the last few years, the use of cloud services has become widespread. According to International Data Corporation (IDC) [37], public spending on cloud services is estimated to reach $107 billion by the year 2017. A large number of cloud service providers (CSP), service brokers, and customers are increasingly taking advantage of cloud features such as elasticity, scalability, universal access, low entry cost, flexible billing, easy metering, and convenient monitoring. Despite the increase in demand and popularity, there are major challenges in moving a business to the cloud, such as compliance, security, and privacy. There are many works considering security and privacy in clouds but we are concerned here only with compliance aspects, which have strong relation to those attributes; in fact, there are relatively few works dealing mostly with compliance aspects.

Regulations are sets of policies that govern the use of sensitive business data. The main intent of these regulations are to protect consumers’ privacy and provide security by enforcing attributes such as confidentiality, integrity, availability, and accountability (CIAA). Compliance implies enforcing the rules that implement the policies defined in the regulations. In the opinion of [41], legal compliance may become the most important Non-Functional Requirement (NFR) for a large number of software systems. Government and state regulations are mandatory while industry regulations are suggestions. Regulations vary from country to country but in many cases they use almost identical policies customized to their local needs. We consider here only US regulations but most of our conclusions apply to non-US regulations. Because of the very nature of cloud technology, compliance is a shared responsibility among organizations and service providers; it involves service providers, service brokers, customers, and auditors. According to the National Institute of Standards and Technology (NIST) [48], organizations are fully responsible for all compliance-related issues. The cost of not being compliant may result in penalty fees, lawsuits, and bad business reputation.

Regulations are often verbose, lengthy, hard to read, redundant, ambiguous, and in some cases even inconsistent. They are indeed documents intended for lawyers not for software developers. We examined in detail only a relatively small number of regulations but the opinion of several authors and people we talked to is similar, e.g. [7, 28, 41]. On the other hand, service providers and consumers are expected to be 100 % compliant and they are often required to comply with more than one regulation. There is a need then for tools to assist enterprises or software houses when implementing software systems that must be compliant, but we have found that the lack of a vendor-neutral standard compliance Reference Architecture (RA) is a basic challenge for service providers, service brokers, consumers, and auditors. An RA is a standardized, generic software architecture, with no platform dependencies, valid for a particular domain [4]. An RA can be used to guide system design and development; it can also be a reference to indicate where the specific compliance policies should be applied in the system architecture. An RA can serve as a common language among stakeholders including business owners, managers, architects, developers, testers, and auditors. References [9, 34, 35, 49, 51, 61] describe RAs intended to guide compliance. There is no accepted definition about what an RA should contain; the available compliance RAs are either vendor specific, lack standard modeling, or are incomplete. In addition, the style and the depth of the architectures are different among vendors. As a result, consumers are challenged to evaluate service providers with no standard compliance RAs that could be used as a common reference and checklist. In particular, when negotiating service contracts it is hard for both consumers and providers to define precisely what it means to be compliant with some regulation. One of the objectives of this paper is to indicate what aspects should be included in such an RA. Some of the regulations have been described by patterns and we indicate also how a catalog of compliance patterns can help to build a compliance RA. We do not provide here an ideal architecture or discuss how to build one, but we have done that in [64].

Often, compliance and security are only addressed either at the testing phase or at the last stage of development, which could potentially result in applications that do not identify potential threats. In order to build good quality and compliant systems, it is critical to consider the enforcement of regulations at all development phases including requirements, design, implementation, and testing phases. An RA emphasizes the need to start from a conceptual view of the semantics of the regulations without getting prematurely involved into implementation details. In [22] we showed the value of an RA as a way to enumerate threats and indicate where countermeasures should be placed. Since compliance is strongly based on security measures and related policies, it is clear that an accepted RA describing specific regulations would provide a way to facilitate building systems that comply with the corresponding regulations. We will consider the use or lack of RAs as a criteria to judge the publications we analyze in our survey. RAs can be built using patterns and use of patterns is another way to make explicit compliance with policies. A pattern is a solution to a recurring problem in a specific context, typically expressed using UML (Unified Modeling Language) models [8].

An RA would be a great help to build new regulations by identifying commonalities. Identifying overlaps and patterns among regulations can avoid duplicate implementations and inconsistencies as well as allow considering known security threats [23]. Reference [28] identified 31 technical security features that are common for FISMA [24], HIPAA [33], PCI [52] and ISO [39]. They concluded that implementing compliance guidelines for FISMA could cover compliance for HIPAA, PCI and ISO with the exception of privacy. Reference [30] built a citation graph to analyze interrelated regulations, overlaps, and possible conflicts. Reference [45] identified overlaps among GLBA, HIPAA, PCI DSS, and SOX regulations. These commonalities are important in complying with multiple regulations and for understanding regulations in general.

Most businesses use independent third party certifying agencies [15] and internal IT auditors to assure compliance, security, and privacy. In addition, government agencies in the US that support cloud computing must fulfill the Federal Risk and Authorization Management Program (FedRAMP) [16]. The US government published the list of FedRAMP certified cloud service providers [15] and Third Party Assessment Organizations (3PAOs) [17] that can be used as a reference for any cloud service providers and consumers. Service providers such as Amazon, IBM, Microsoft, Oracle, HP and others claim compliance by certifying their cloud services with 3PAOs. We survey here some industrial compliance efforts. Based on the survey of publications and industrial practice we discuss their significant issues and provide guidance about how this architecture should be.

Section 2 describes some background about regulations, patterns, and RAs. We survey compliance publications in Section 3 and compliance approaches in industry in Section 4. Section 5 summarizes compliance issues and recommendations. We end with some conclusions and future research directions in section 6.

2 Background

In this section we describe some background about regulations, standards, patterns, and RAs.

2.1 Regulations and standards

We summarize below some of the common regulations in the U.S.

HIPAA (Federal regulation): Healthcare organizations are required to comply with the Healthcare Insurance Portability and Accountability Act (HIPAA) [33]. The main objective of HIPAA is to ensure the security and privacy of Protected Health Information (PHI). PHI includes patient medical records, personal information, credit information, insurance, employment information, and any related information that helps to identify an individual. HIPAA categorizes participating entities as covered entities and business associates. Covered entities include health care providers, health insurers, and health care clearinghouses (i.e. entities that manage billing services and process medical records that come from other systems). Business associates are entities that transfer, store, and service protected health information on behalf of covered entities. HIPAA has five major rules [33]:

• Privacy rule: health providers must notify individuals of the use of their health information. In addition, health providers must regulate the use and disclosure of PHI.

• Security rule: regulates the security of PHI from breaches, unauthorized access, deletion, and modification held by covered entities and business associates. This rule complements the Privacy rule by defining ways to protect its information.

• Transaction and Code Sets rule: Regulates medical transactions, medical coding standards, and reporting.

• Enforcement rule: it sets money penalties for violating HIPAA rules and establishes procedures for investigations and hearings for HIPAA violations. It regulates the use and disclosure of Protected Health Information for law enforcement officials.

• Unique identifier rule: prescribes that employers and participating parties are required to have unique Employer Identification Numbers (EIN) to use for their transactions. Each medical transaction is required to have a unique ID and code set.

PCI-DSS (Credit Card industry regulation): Companies that handle cardholder information are required to comply with the Payment Card Industry Data Security Standard (PCI DSS) [52]. Cardholder information includes debit, credit, prepaid, ATM, and Point of Sale (POS) cards. PCI recommends that only authorized users have access to manage cardholder data. PCI has twelve major rules to protect cardholder data including installation of firewalls, resetting default password and security parameters, authentication, authorization, encryption, and others. Its rules are as follows [52]:

• Install and maintain a firewall configuration to protect cardholder data

• Do not use default passwords or security parameters

• Protect stored cardholder data

• Encrypt transmission of sensitive information across public networks

• Use and regularly update anti-virus and malware protection

• Develop and maintain secure systems and applications

• Restrict access to data by using a need-to-know policy

• Identify and authenticate access to system components

• Restrict physical access to cardholder data

• Track and monitor access to network and cardholder data

• Regularly test security systems and processes

• Maintain an information security policy

Sarbanes-Oxley Act (SOX) (Federal regulation): SOX establishes standards for all US publicly-traded companies to protect shareholders and the general public from accounting errors and fraudulent practices [57]. SOX enforces control on user management, auditing, reporting, security and privacy analysis, authorization, authentication, system development, program and infrastructure management, monitoring, backup, and disaster recovery. Its rules are as follows [57]:

• Establish safeguards against fraudulent financial report, including data accuracy and correction timeline.

• Disclose compliance and security safeguards to independent auditors, including security policies, changes, application and system logs, and operations.

• Establish safeguards to prevent unauthorized data tampering

• Establish safeguards to track data access and changes

• Regularly test security systems, policies, and processes

• Maintain an information security policy

• Detect and notify security breaches

Gramm-Leach-Bliley Act (GLBA) (Federal regulation): It requires institutions that offer financial products or services to consumers to develop, implement, and maintain a comprehensive information security program that protects the confidentiality and integrity of customer records [29]. Its rules include:

• Privacy rule - disclosure policies and procedures on how consumer’s data is protected and used.

• Safeguard rule – maintain comprehensive security policies. Security policies need to be applied to all with no exception and need to be reviewed, tested, and maintained frequently.

Control Objectives for Information and Related Technology (COBIT), (IT industry regulation): It is a standard to provide IT governance and control. It attempts to ensure the integrity of information and information systems by providing technical guidelines on information security, compliance, governance, audit, and risk management [11].

The Federal Information Security and Management Act (FISMA), (Federal government regulation): FISMA applies to government agencies and affiliated companies that collect and process data on behalf of government agencies [24]. It provides guidelines on security controls, user access, identity management, risk assessment, auditing, and monitoring.

ISO/IEC 27000 (IT industry regulation): It is a general security guideline for all types of organization including commercial enterprises of all sizes [39]. It is a family of standards that helps organizations to secure information assets. Some of its standards are:

• ISO/IEC 27001 –Information security management systems requirements

• ISO/IEC 27002 – Code of practice for information security controls

• ISO/IEC 27003 – Information security management system implementation guidance

• ISO/IEC 27004 - Security techniques -- Information security management

ISO/IEC 27002 defines six access control objectives that cover end user, privileged user, network, application, and information. The objectives include control access to information, manage user access rights, apply good access practices, control access to network services, control access to operating systems, and control access to applications and systems [42].

These regulations and standards are used in service sectors such as healthcare, finance, retail, communication, energy, education, and government agencies. Table 1 shows a summary of a few service sectors with their corresponding regulations. In most cases, service sectors support multiple regulations to comply with government and industry regulations. As mentioned earlier, many countries have similar regulations and standards customized to their local needs. For example, the European Union Data Protection Directive law (EU DPD) has a set of policies to protect the confidentiality, integrity, availability, and accountability of personal data [44]. EU countries are required to comply with these policies.

Table 1 Summary of service sectors with their corresponding regulations

2.2 Patterns

A pattern encapsulates a solution to a recurring problem in a specific context. Patterns can be used to analyze complex systems, to capture design decisions, assumptions, and experiences. They can improve software quality by promoting reusability, scalability, and consistency. Patterns can be categorized as analysis patterns [19, 25], design and architecture patterns [8, 26], and security patterns [18, 20]. Pattern solutions are usually represented using modeling languages such as the Unified Modeling Language (UML), maybe combined with formal languages such as the Object Constraint Language (OCL) [63]. Patterns may include class diagrams, sequence diagrams corresponding to use cases, and state diagrams, and they are described using templates. A few patterns exist to describe the architectural implications of regulation policies [14, 21].

2.3 Reference Architectures (RAs)

As defined earlier, a Reference Architecture (RA) is a generic abstract architecture, valid for a particular domain (or set of domains), with no implementation aspects or vendor specific details [4, 60]. RAs are special types of architectures intended to understand, analyze, design and standardize complex systems at a high level of abstraction. RAs are reusable, extendable, and configurable; that is, they are kinds of patterns for whole architectures and can be instantiated into specific software architectures by adding platform aspects. Software architectures derived from RAs could mitigate risks, facilitate compliance, and protect confidentiality and integrity of consumers’ data [10, 62]). RAs can become a common language among stakeholders including business owners, managers, architects, developers, testers and auditors. RAs can also be used to standardize application design, implementation, and verification. RAs can be built of patterns and there is also a possibility of identifying new patterns while building them. In addition, block diagrams, reference models, viewpoints, use cases, and formal languages can be used to build RAs.

3 Survey of compliance in cloud computing

There are only a few papers that have direct relationship to our survey. We review papers that discuss general aspects of regulations or which consider compliance with specific regulations.

Reference [48] identified a number privacy and security related issues that could have an impact on cloud computing. The paper covers issues and recommendations on governance, compliance, trust, architecture, identity, access management, software isolation, data protection, availability, and incident report. The paper pointed out that compliance in cloud computing is one of the complex issues to deal with as policies vary from country to country. As per [48], understanding and enforcing regulations are also a major challenge in cloud computing. They analyzed the impact of data location, loss of control, and transparency in public cloud compliance. The issue of electronic discovery that involves identification, collection, processing, analysis, and production of stored information is also covered. The authors didn’t cover techniques to map complex policies into best practices, patterns, or RAs. They also mentioned that most cloud service providers use third party certification to confirm their compliance. As per our survey, third party auditors are using proprietary solutions that lack vendor neutral models or architectures that can be used as a checklist by all stakeholders.

Reference [45] compared GLBA, HIPAA, PCI and SOX standards on the basis of generating reports for auditors. Their findings showed that some reports and services share common features including user logon report, user logoff report, user failure report and logs access report as shown in Table 2. They concluded that SOX compliance with respect to reports also covers the required reports for GLBA, HIPAA and PCI-DSS. The authors didn’t cover other features of compliance such as privacy, security, user management, and notification. The comparison table would have been more precise if it was backed by more precise artifacts.

Table 2 GLBA, HIPAA, PCI DSS and SOX report comparison [45]

Reference [55] analyzed the top seven threats and their possible impact on cloud compliance by mapping threats to applicable regulations. The mapping could be used as a reference to evaluate compliance. However, the paper lacks explicit mappings between compliance and security threats. For example, in Table 3 threats # 2 and #3 are not mapped to any compliance standard. The paper also lacks a precise definition of threats and their corresponding correlation with compliance. For example, they consider threats #2 and #3 as threats but they are vulnerabilities. The authors left out other regulations such as SOX and GLBA and did not try to define an RA. Note also that this list of threats is rather incomplete; for a more comprehensive list see [31, 55].

Table 3 Threats to compliance mapping

Reference [54] reviewed privacy regulations in the cloud. They pointed out that there are still many uncertainties with respect to compliance and privacy in cloud computing. As a result, it is becoming very difficult to analyze security, privacy and compliance among cloud service providers. In addition, they indicated that many regulations share common requirements such as privacy, integrity, security and enforcement. They mentioned that organizations are liable in the case of security breaches and lawsuits. They also reviewed the use of independent third parties to certify compliance.

Reference [46] analyzed HIPAA and COBIT with respect to NIST guidelines. According to [46], healthcare organizations that adopt COBIT as their standard will immediately satisfy 50 % of the NIST standards. They concluded that an increase in security threats, complex regulations, lack of qualified security experts, and high implementation and maintenance costs are the most common challenges in the healthcare industry. In addition, the authors pointed out that company compliance can be improved by analyzing regulation overlaps and best practices. The overlap was presented in block diagrams which do not show clearly the type and the nature of these overlaps.

Reference [30] built a citation graph that could be used by analysts to navigate through the various interrelated regulations to uncover overlaps and possible conflicts or to understand compliance documents. The authors used a decision support system to identify compliance similarities and differences. They used this citation graph to understand regulations, to uncover overlaps and possible conflicts. They also use the citation graph to detect important provisions by ranking, to assess the impact of change in a particular act, and to validate consistency. The overlaps include security, notification, reporting, and user management. The authors focused only on HIPAA, SOX and GLBA regulations. We can also assert that [45] findings confirm [30] conclusions.

Reference [6] developed a compliant cloud computing (C3) framework to address security, compliance, privacy, and trust issues. According to the authors, C3 can be used to address data privacy by enforcing data storage in specific regions and by applying data fragmentation. They claim that the framework can be used as a broker to integrate multiple service providers. The authors proposed a domain specific language (DSL), a metamodel and an activity diagram to analyze regulations such as HIPAA, PCI and SOX.

Reference [13] developed a framework called MEGHNAD [13] that uses a Multi-Objective Genetic Algorithm (MOGA) to determine an optimal security toolset that could meet security and compliance requirements. The authors claim that the framework can be used to generate compliance checklists and Service Level Agreements (SLAs). They also used the framework to analyze security levels and cloud assurance levels for IaaS, PaaS and SaaS.

According to [12], security and compliance tools could help organizations to certify compliance. They reviewed compliance tools such as WatchGuard and Trust Wave to analyze, and generate compliance coverage reports. The depth and scope of the reports vary from vendor to vendor. The authors categorized service models and defined a compliance mapping matrix based on “who controls what” as shown in Tables 4 and 5. The definitions in these tables are not detailed enough to show precisely the roles of the users of a cloud. For example, access control is a shared responsibility but it is indicated as vendor responsibility in Table 4. In Table 4, requirements 3 and 5 are the same by definition; however, the authors provide different roles for IaaS responsibility. They covered HIPAA and PCI standards but these conclusions may not apply to other standards. The authors suggested that more research needs to be done in order to build consumers’ confidence and trust.

Table 4 Vendor responsibility for HIPAA Requirement Mapping matrix [12]

Table 5 Vendor responsibility for PCI DSS Requirement Mapping matrix [12]

Reference [47] discussed PCI compliance challenges and solutions. The authors reviewed challenges such as costs, overlaps, legal uncertainties, security, maintenance, complexity, code quality, and new technologies. Their proposed solutions are based on best practices. The solutions include authentication, authorization, encryption, and monitoring. The authors didn’t cover how to address regulation complexities and overlaps.

Reference [28] analyzed security overlaps among FISMA, HIPAA, PCI and ISO. The author identified 31 technical security features that are common to FISMA, HIPAA, PCI and ISO and suggested that implementing the compliance guidelines of FISMA could cover compliance of HIPAA, PCI, and ISO, with the exception of privacy. The paper also confirms regulation overlaps and the need for the systematic approaches proposed by [45, 47, 55].

Reference [44] reviewed the EU DPD law and regulations in the context of cloud computing. They pointed out that parts of the DPD policies are not clear, including the definition of sensitive personal data, the roles of controllers and processors. The authors also mentioned that there are overlaps among regulations. They used an enumeration approach to map the DPD policies to available best practices. They proposed encryption, anonymization, and pseudonymization to secure personal data in the cloud. One of the problems with enumerations is that they lack a conceptual model of how the requirements relate to each other.

Reference [14] proposed a Compliance Request Languages that can be used to specify compliance patterns that can be applied to business processes. They built design-time compliance management framework that can be used to automate compliance validation and verification. They made no attempt to define a precise model for their framework.

Stricker et al. [58] built an RA for service-based systems using a pattern-based approach. The architecture contains top-level patterns, abstract patterns, and implementation patterns. They proposed to include a component catalog as part of the architecture. However, [58] did not include a method to map identified components into abstract patterns. Fernandez et al. [22] developed a security reference architecture (SRA) for cloud systems from use cases, threat modeling, and patterns; it maps identified components into abstract patterns using a catalog. We proposed a five-step approach to build RAs using metamodels, patterns, and best practices [64]. First, we analyzed RA input sources from functional requirements, non-functional requirements, stakeholders, regulations and standards. We identified components from use cases, ontologies, threat modeling, policies and best practices. Second, we built a conceptual model (RM) by analyzing domain components, stakeholders and their interactions. We used UML to analyze the static and dynamic nature of the identified components. Third, we mapped the identified components to patterns using abstract patterns. Fourth, we built RAs by combining results from steps 1, 2 and 3. Fifth, we evaluated the architecture by validating its quality attributes such as accuracy, completeness, modularity, reusability, flexibility, and readability. These architectures, [22, 58, 64], can be used to analyze both functional and non-functional aspects such as security and compliance at the architectural level.

In summary, we can conclude that many of the proposed solutions are not approaching compliance challenges at the architectural level using appropriate models. All approaches discussed in this section, except [22] and [64], don’t use a comprehensive metamodel that includes both functional and non-functional requirements at the architectural level as shown in Table 6. As a result, many RAs are either incomplete or do not follow standard models or architectures. In addition, the proposed solutions and architectures can be more understandable and precise if they used standard models, patterns, and architectures.

Table 6 Summary of Related Work

4 Compliance approaches in industry

Most businesses use independent third party certifying agencies and internal IT auditors to assure compliance, security, and privacy [15]. The US government published the list of FedRAMP-certified cloud service providers and Third Party Assessment Organizations (3PAOs) that can be used as a reference for cloud service providers and consumers [15, 17]. Reference [15] recommends that consumers review and approve compliance reports and certificates before signing the service contract. Service providers are using 3PAOs and internal auditors to certify compliance. In addition to third party compliance certification, many service providers use enumeration to claim their completeness. The problem with enumerations is that they do not provide a measure of completeness and lack a conceptual model of how the requirements relate to each other and to the system.

Service providers such as Amazon, IBM, Microsoft, Oracle, HP, Cisco, Hitachi, and others claim compliance for HIPAA, PCI, FISMA, SOX, and GLBA. References [2, 35, 49] describe RAs for clouds with conceptual and logical views that include security management and compliance. Their architectures use models and enumeration to describe components and their interactions. Amazon Web Services (AWS) published a list of compliance eligible services such as DynamoDB, Elastic Block Store (EBS), Elastic Cloud Compute (EC2), Glacier, Redshift, Elastic MapReduce (EMR), Simple Storage Service (S3), Identity and Access Management (IAM), CloudTrial, CloudHSM, and Amazon Relational Database (RDS) to protect customers’ data at rest and in motion [1, 3]. Reference [51] published an RA for PCI-DSS using specific products such as VMware, Cisco, Trend Micro, and HyTrust; this architecture maps PCI rules to hardware and software products. Reference [61] describes a compliance Reference Architecture Framework (RAF) to address requirements at the infrastructure, application, and end user computing layers. Infrastructure layer compliance includes network security, configuration management, log management, and platform security. Application layer compliance includes permissions and governance, service level agreement, and data security. End user computing layer includes identity management, end point security, authentication, and authorization. Reference [61] maps regulation policies to corresponding layers and VMware products. Reference [10] built regulatory compliant architectures using a risk management framework to address functional capabilities, operational reliability, regulatory compliance, and security. The framework uses a standard enterprise layer architecture (i.e. web layer, application layer, service layer, business, and data layers) to identify components, and map compliance policies to corresponding Cisco products. References [10, 62] proposed a compliance reference architecture by abstracting regulations and corporate policies. References [43, 62] use SOX and Microsoft products to identify components, build the architecture, and map compliance policies to appropriate Microsoft products. Reference [34] proposes a compliance architecture derived from regulation overlaps among corporate governance and regulations. Reference [35] enumerates policies from regulations and maps them to proprietary identity and access management products.

Compliance in the cloud is a shared responsibility among service providers and consumers [53]. The responsibility of service providers and consumers vary based on the type of their service models. In the case of IaaS, consumers are responsible to secure services, platforms, and data. Service providers are responsible to secure the infrastructure. In the case of PaaS, consumers are responsible to secure services and data; service providers are responsible to secure platforms and infrastructures. In the case of SaaS, consumers are responsible to secure data; service providers are responsible to secure services, platforms and infrastructures. In general, the lack of full control and transparency creates compliance challenges in the cloud.

In summary, most service providers have published compliance architectures, designs, and implementations based on their own proprietary cloud platforms, infrastructures, and products. The available RAs published by service providers are either vendor specific or do not follow standard models, patterns or architectures. As a result, it is very difficult to analyze their level and scope of compliance. Consumers are also challenged to evaluate service providers without having standard RAs and models that could be used as a common reference and checklist.

5 Summary of compliance issues and recommendations

In this section we summarize five major compliance issues.

5.1 Complexity of regulations

As indicated earlier, regulations are written by lawyers and often lengthy and hard to read. In some cases, the rules are redundant, ambiguous, and even inconsistent. Regulations also vary from country to country. There have been attempts to make regulations clearer and more precise by using block diagrams, citation graphs, and reference models. However, there have been only a few attempts to make their software architecture more precise in order to understand and analyze policies at a higher level and eventually guide design and implementation efforts. Reference [21] described the major HIPAA rules as patterns, to make HIPAA clearer and more precise. These HIPAA regulation patterns include: HIPAA security rule, HIPAA privacy rule, HIPAA transactions and code sets rule, HIPAA unique identifiers rule, and HIPAA enforcement rule. Figure 1 shows a UML class diagram for the HIPAA security rule [21]. It shows its major components, entities, and their associations. It includes Role-Based Access Control Authorization, Authenticator, and Security Logger/Auditor patterns [18]. We need to identify more patterns for regulations to make regulations clearer and more precise.

Fig. 1

Class diagram for HIPAA’s security rule [21]

5.2 Regulation overlaps

Our survey reveals that there are overlaps among regulations such as HIPAA, PCI, SOX, GLBA and FISMA [23, 30, 45, 46]. Most cloud service providers are required to support multiple regulations in order to fulfill consumers’ needs. The cost of implementing individual regulations can lead to high implementation and maintenance costs, duplication of efforts, and inconsistencies. Hamdaqa and Hamou-Lhadj [30]; Mirković [45]; Netschert [46] attempted to identify overlapping features such as security, user management, notification, and reporting. Reference [30] used a citation graph to identify overlaps. These overlaps could incur unnecessary cost and maybe inconsistencies. There has been only one attempt to identify these overlaps at the architectural level [23].

5.3 Lack of standard Reference Architectures (RAs)

There is no accepted definition about what an RA should contain; [4] provide ways to describe and evaluate RAs by using IEEE recommended architectural description practice [38], Rational Unified Process (RUP) artifacts [40] and UML [5]. Reference [58] built an RA for service-based systems using patterns. Reference [22] built an RA for cloud systems with use cases, activity diagrams, and patterns. We can observe that there are different levels of understanding and approaches to build RAs. In addition, the style and the depth of the architectures are different among service providers. On the other hand, consumers are challenged to evaluate service providers’ compliance without having a standard checklist. We can conclude that available approaches don’t use a comprehensive metamodel that includes both functional and non-functional requirements. As a result, many RAs are either incomplete or do not follow standard models or architectures. We proposed a five-step approach to build RAs using metamodels, patterns, and best practices [64] (see Section 3). Figure 2 shows a UML class diagram of a compliance and security RA (CSRA) from a SaaS service provider perspective. The architecture includes major regulation components, stakeholders, cloud components, patterns, and best practices. There are other approaches to build RAs but we think that this is the first one that takes advantage of patterns to properly represent regulations.

Fig. 2

A CSRA for SaaS service provider perspective [64]

5.4 Lack of full control and transparency

The lack of full control and transparency is also one of the compliance challenges in the public cloud [44, 48]. The data stored in the public cloud could be replicated in different regions and / or countries that could violate privacy laws of other countries. In addition, service providers are required to ensure the confidentiality, integrity, availability and accountability (CIAA) of consumers’ data as per the government and industry regulations. Reference [6] developed a framework that can control data location while maintaining compliance. Reference [12] suggested more research to build consumers’ trust and compliance.

5.5 Security threats

Cloud services like any IT platforms are subjected to a variety of security threats [31, 50]. The complexity and shared responsibilities of cloud computing are also another security threat that could affect the overall compliance. Cloud computing is relatively new and still changing. More research is needed to build consumers’ confidence and trust by identifying potential security and compliance threats. Reference [22] developed a security reference architecture to enforce cloud security. The architecture can be extended to support compliance by adding compliance patterns and best practices. The architecture proposed in [64] follows this approach and can handle identified threats by including appropriate security patterns as shown in [22].

5.6 Overlap with security

Most of compliance has to do with security. However, compliance is often handled by different groups who don’t have a full expertise on security. Looking at some of the recommendations in the publications we surveyed we find that many of them are rather naïve and not enough to provide a highly secure architecture.

6 Conclusions and future directions

We have analyzed the state of the art in complying with regulations by examining recent publications and surveying industrial approaches. Regulations and standards are complex, possibly redundant and even inconsistent in some cases. A good way to handle compliance complexities, uncertainties, and overlaps is by applying standard models, patterns, architectures, and best practices. There have been attempts to analyze regulation policies and overlaps. However, there has been no attempt to make their software architecture more precise at a higher level to eventually guide design and implementation efforts. These kinds of standard approaches could improve compliance, security, privacy and the overall software quality of cloud systems. We examined how publications and industry have considered this particular aspect as a measure of their ability to cope with an increasing complexity. While there are other aspects that affect compliance we have taken the proper use of architectures as a key point.

Our survey reveals that more research is needed to overcome compliance challenges. Reference [21] described the two major HIPAA rules as patterns to make HIPAA clearer and more precise, but we need to identify more regulation patterns by analyzing available regulations, standards, and policy based systems. A collection of patterns can be used to build pattern-based compliance RAs [64]. We need to develop a complete and precise RA that can be used to analyze complex regulations, avoid overlaps, mitigate security threats, and promote the usage of patterns. We proposed a five-step approach to build RAs using metamodels, patterns, and best practices [64]. We have built an RA for HIPAA and CSRA for cloud systems with the proposed five-step approach. An architecture built out of patterns can be used as a common language among architects, developers, business owners, managers, service providers, and auditors. It can also be used as a reference to design and implement automated systems that can be used for testing, auditing, and compliance verification. We need to build more RAs in the areas of services, platforms, regulations, and policy-based systems to improve software quality. It is very important to convince industry that they need to adopt more abstract compliance architectures that provide greater flexibility and adaptability to new and evolving regulations. We need also to merge the work on compliance with the work on security and provide a unified approach that considers both aspects.