Chapter 7

Auditing in the Cloud

Two thirds of the earth’s surface is covered with water, the other third is covered with auditors from headquarters.

—Norman R. Augustine

Historically, data has been stored behind corporate firewalls in the control of the company that owns the data. It was up to the company to secure the perimeter, harden the infrastructure, and secure the databases. Auditors could come on-site and inspect the processes and controls to make their assessments. If any government agency wanted to seize any data for an investigation, it had to confront the company before doing so. The bottom line was the company that owned the data was in control. That is not the same as saying the data was secure, but responsibility for securing the data was owned by the company.

Storing the data in the cloud is a different story. Now the company has a shared responsibility with the cloud service provider (CSP) and the further up the cloud stack they go, the more responsibility the CSP takes on. In some respects this is a good thing. Why not let the CSP, whose core competencies include security and compliance, handle some of the heavy lifting around securing and encrypting data, hardening the environment, managing backup and recovery processes, and various other infrastructure-related tasks? Off-loading security and compliance to a CSP does not mean that the company is no longer accountable. It simply means the CSP provides secure and compliant cloud services, but it is still up to the company to secure the overall application. When security and compliance are shared responsibilities, auditing the entire solution becomes a more complex situation. Now auditing must occur across multiple entities: cloud service consumer and cloud services provider(s).

This chapter will discuss the cloud security, what auditors look for in cloud applications, briefly review common regulations, and then cover various design strategies for auditing cloud services.

Data and Cloud Security

Study after study and poll after poll consistently point to security in the cloud as the number-one concern of both business and IT people. Some of these concerns are valid but some are based on assumptions and fear. IT people are used to being in control of their data and systems. Letting someone else manage critical data is a foreign concept to many, and the immediate reaction is to assume that if it is out of our control, it cannot be as secure. A recent study by Alert Logic in the spring of 2013 came to the following conclusions.

• The cloud is not inherently less safe than enterprise data centers.
• Attacks in CSP environments tend to be crimes of opportunity, while those in enterprise data centers tend to be more targeted and sophisticated.
• Web applications are equally threatened in cloud and enterprise data centers.

What this means is that it doesn’t matter where the data resides—the threats are the same. What was more interesting in the study was that the success rate of penetrations from outside threats was much higher in enterprise data centers than in CSP environments. This should not be much of a surprise since security is a core competency of CSPs. Without world-class security, many would not be in business today. Many corporations do not have the resources and expertise to build a world-class secure data center.

Based on this information, skeptical architects and product managers need to dismiss the notion that data cannot be secure in the cloud and focus on the real issues and constraints around auditing, laws and compliance issues, customer requirements, and risks.

Auditing Cloud Applications

Auditors are responsible for validating that their clients adequately address a collection of controls and processes in order to receive a stamp of approval for satisfying the requirements of a given set of constraints as defined by a governing set of laws. There are many different regulations that exist today. In order for a company to determine which regulations apply to it, the company must have a firm understanding of its industry’s standards, business processes, and data requirements. When dealing with IT systems, auditors validate the process and controls in the following areas (when necessary):

• Physical environment. Perimeter security, data center controls, and so on.
• Systems and applications. Security and controls of network, databases, software, and the like.
• Software development life cycle (SDLC). Deployments, change management, and so forth.
• Personnel. Background checks, drug testing, security clearance, and more.

Before cloud computing, an auditor could sit down with a client and map personnel and physical infrastructure to the different controls and processes that were to be audited. Auditors had access to physical data centers whether they were located at a client’s property or at a third-party facility. In either case, the auditors could point to a physical machine and inspect the physical security of the data center. In the cloud, this is not the case. Now, certain controls and processes map to a CSP instead of to an individual. When that occurs, the auditor must rely on the auditing information produced by that CSP, hence the reason why compliance is such a high priority in the cloud. Without proof of compliance, a CSP could cause a customer to fail its audit. This is one major reason why some companies prefer to build private clouds. They want to be in total control of the data, the processes, and the controls and not rely on another entity when it comes to security, privacy, and regulation. The irony of that decision is that in many cases, it would be easier and more cost effective to rely on CSPs if certain functions of the application were managed by certified CSPs.

A public Infrastructure as a Service (IaaS) environment is a multitenant environment, meaning multiple customers share compute resources. The IaaS provider will not allow an auditor of one of its tenants to access the infrastructure because it has an obligation to protect the rights of all of the other tenants. The IaaS provider will have its own auditors audit its perimeter security, processes, and controls, but no tenant’s auditor will be able to physically access the actual infrastructure (the tenant has no idea what infrastructure it is running on, anyway). Auditors will be forced to inspect the white papers and published audit reports that the IaaS providers produce and will have no access to public IaaS data centers. For private IaaS data centers, auditors may have access to inspect the actual infrastructure to access the physical perimeter security unless the private cloud is hosted by a CSP.

With Platform as a Service (PaaS) CSPs, the physical aspects of auditing are even more complex. Not only is the infrastructure abstracted and managed by the CSP, the application stack is, too. Tasks like monthly patching, locking down the operating system, intrusion detecting, and others are all managed by the CSP. In some instances, even the database is controlled and managed by the CSP, and the customer only controls the database access and administration of users. Even more responsibility is outsourced to the CSP with Software as a Service (SaaS) applications. In addition to being responsible for the infrastructure and application stack, SaaS providers also have responsibility for the entire application. Consumers of SaaS solutions have very limited responsibilities in this case. In Chapter 9, “Security Design in the Cloud,” we will discuss this in great detail.

Why is all of this important? There are a number of regulations that must be adhered to if a company wishes to operate certain business processes in the cloud. Many customers will not do business with a company that offers cloud services that are not in compliance with various regulations. For example, a U.S.-based company offering cloud-based services for automating health records processing on behalf of health care providers will have a very hard time finding a customer if it is not HIPAA compliant. HIPAA is the Health Insurance Portability and Accountability Act put in place by the United States federal government that requires health care providers to apply appropriate levels of administrative, technical, and physical controls to ensure the privacy of consumers’ protected health information (PHI). Health care providers are very unlikely to engage with a CSP that is not HIPAA compliant because by doing so, the health care provider may fall out of compliance, which could lead to unpleasant consequences for its business, such as fines, legal issues, lost business, and bad publicity.

It is important that architects and product managers understand who is responsible for the data within each service model and how that responsibility is accessed in the audit process so the appropriate processes and controls can be put in place. It is equally important to understand when certain regulatory requirements are in scope, which leads us to our next section.

Regulations in the Cloud

There are a number of regulations that apply to systems being built in the cloud. Some are industry specific, some are specific to the type of data and transactions that are being processed, and others are standards for any cloud-based system. For companies building software in the cloud, there are two parties that have a responsibility to adhere to compliance: the CSP and the company building the applications. The fact that a company like Amazon Web Services (AWS) is certified for the ISO 27001 standard does not make the applications built on top of AWS compliant. It simply means the infrastructure layer can pass the audit. The company building and managing the application stack and application layer has to have all of the proper controls in place to ensure that the entire application can pass the audit. Table 7.1 offers a list of some of the regulations that can come into play when building cloud services.

Table 7.1 Regulations and Controls

To pass audits pertaining to software best practices, security, and privacy, a company must have controls and processes in place in the following categories:

• Incident management
• Change management
• Release management
• Configuration management
• Service level agreements
• Availability management
• Capacity planning
• Business continuity
• Disaster recovery
• Access management
• Governance
• Data management
• Security management

This is another reason the myth that cloud solutions are not secure is completely false. In order to become certified for the standard regulations for cloud computing, a company must pass audits by implementing approved processes and controls in all of these categories. Many on-premises solutions were never held to that same standard. We will discuss some of these categories in detail later in the book.

There are many more regulations that can fall into scope. Each country may have its own laws that must be adhered to, as well. The type of application and the customer base have a lot to do with the regulations that apply. For example, many social media sites do not feel the need to invest in passing various audits. Most simply post terms and conditions of what the company’s responsibilities are and the user accepts them as is in return for using the services. For business-to-business (B2B) companies, adherence to regulations is much stricter. Customers of CSPs that are corporations have much greater responsibility and requirements than individual consumers. For example, an individual using a cloud service like Twitter can choose to opt in and assume the risks as defined in the terms of services or she can choose to not enroll. If an individual opts in, she relies on Twitter to uphold its part of the agreement by keeping her data secure and private. If Twitter fails to do so, there is not much an individual can do other than choose to close her account.

Now let’s look at Chatter, a Twitter-like cloud service for social collaboration within the enterprise. Even though Twitter and Chatter are conceptually very similar services, the risk of a breach of Chatter data is exponentially more serious than Twitter data. The reason is because Chatter is used internally for business discussions and to connect with customers and suppliers. The information shared using this technology is not for public knowledge. A breach could expose a company’s secrets, upset customers and partners, and create a public relations nightmare for the company. Salesforce.com, the company that sells Chatter services, must comply with numerous regulations in order to gain the confidence of businesses if they are to become paying customers.

Here is what decision makers need to know when it comes to regulations. For Infrastructure as a Service (IaaS) and PaaS CSPs, gaining certifications for numerous regulations is a key to customer acquisition. Minimally, a CSP should be certified in ISO 27001 and SSAE-16 SOC1 and SOC2. If the provider expects to have health care customers, it should get certified in HIPAA. PCI compliance is critical if the CSP expects any type of application that accepts payments to be run on its infrastructure. There are a variety of government regulations like Federal Information Processing Standards (FIPS) and the Federal Risk and Authorization Management Program (FedRAMP) in the United States that certain government agencies require CSPs to comply with. Often, companies and government agencies leverage private cloud IaaS and PaaS solutions to get around the lack of certifications in the public cloud space. In these cases, the risks far outweigh the benefits of elasticity and resource pooling that are sacrificed when cloud services are performed in a private cloud setting. Recently, public IaaS providers have been getting certified in federal regulations in an attempt to attract business from government agencies. AWS has launched a dedicated region called GovCloud that meets the regulatory requirements of the government and isolates the government applications installed in that region from the rest of AWS’s customers. This is a semiprivate community cloud running on a public IaaS only for certain government agencies.

For SaaS CSPs, privacy is a key issue because all of the data management is the responsibility of the service provider. Most SaaS contracts have a software escrow provision to account for what happens to the data if the solution is unavailable for a long period of time or if the company goes out of business. The software is deposited in a third-party agent’s escrow account and turned over to the consumer of the SaaS solution if the CSP declares bankruptcy or fails to meet the contractual obligations. CSPs that transfer data across international boundaries must meet the regulatory requirements of the safe harbor law. EU safe harbor law prohibits the transfer of personal information to and from European Union (EU) countries to non-European companies that do not meet the EU standards for privacy. Any SaaS provider hoping to sell to EU countries or customers that integrate with EU customers will have to adhere to EU regulations as well as many of the regulations just listed. The good news is that there is a great deal of overlap in these regulations. The combination of ISO 27001 and PCI regulations are a superset of a majority of the remaining regulatory requirements. Some auditors even have the capability to combine the auditing efforts into a single engagement so that they can audit all of the processes and controls in one pass and produce multiple audit reports, thus reducing the overall cost and time to complete the audits.

Audit Design Strategies

The first step of an audit design strategy for a new cloud application is to identify all of the regulations that apply based on the requirements from customers and the industry. Most cloud services targeting business customers will be required to be compliant with an IT best practices regulation like the ISO 27001 standard and a security regulation such as the SSAE-16, SOC 2 regulation. Other factors that dictate additional regulations are:

• Industry requirements (health care, government, education, etc.)
• Data types (payments, personal identifiable information, etc.)
• Location (country, transmission across country boundaries, etc.)

Once the team has established the list of regulations that it must adhere to, the next step is to create a work stream in the product roadmap dedicated to auditing. This work stream should be made up of the following strategies:

• Data management (Chapter 8)
• Security management (Chapter 9)
• Centralized logging (Chapter 10)
• SLA management (Chapter 11)
• Monitoring (Chapter 12)
• Disaster recovery (Chapter 13)
• SDLC and automation (Chapter 14)
• Operations and support (Chapter 14)
• Organizational change management (Chapter 15)

A key takeaway here is that the product has to evolve over time. There is much to do within each strategy before attempting to pass an audit. A wise strategy would be to take an enterprise view for each of these strategies, so subsequent applications can leverage the initial investment, and future cloud applications can be implemented in a consistent manner reducing maintenance costs and improving auditability. Addressing auditing requirements after applications are built is a very expensive undertaking and often results in process and control gaps. When auditing requirements are considered early in the development, processes and controls can be designed to be part of the core application, thus making reducing risks, improving auditability, and reducing auditing costs easier.

The amount of development required to build a system that can pass audits is greatly impacted by the cloud service model that a cloud service consumer chooses. When building on top of IaaS, a large amount of the responsibility falls on the cloud service consumer. If the consumer chooses to build its own private cloud on its own premises, the consumer has total responsibility to build in all of the necessary processes and controls. Leveraging a public IaaS or a hosted private IaaS provider off-loads the responsibility for the infrastructure layer to the CSP. Obviously, as we move up the stack to PaaS and SaaS, more responsibility shifts to the CSPs, but the consumer still needs some level of process and controls in each area.

Another key factor of an auditing strategy is the maturity of the consumer. If the consumer is a start-up, it is likely that getting to market quickly is far more important than passing audits. In fact, there is no use putting all of the effort into auditing until the start-up can validate that there is a sufficient demand for its products and services. That is not to say that start-ups should ignore auditing requirements altogether. They should be able to at least answer to customers regarding how they plan on addressing auditing requirements. A well-established company that sells into fortune 500 companies will likely be required to pass the audits prior to launching its products and services.

One of the best examples of implementing an auditing and compliance roadmap is Amazon and its AWS product. Amazon first launched its S3 and EC2 web services to the public in 2006. It wasn’t until 2010 that AWS announced it was compliant with ISO 27001 and PCI DSS. In 2011, it announced the publication of the SSAE-16 SOC 1 report. In 2013, it published the SSAE-16 SOC 2 and SOC 3 reports and achieved FedRAMP compliance. This compliance roadmap was driven by customer demand. When AWS first launched and for the following two to three years, it was primarily used by start-ups, web applications, and for ad hoc applications. In order to attract more mainstream customers, Amazon targeted the ISO 27001 standard. Once it was certified for ISO 27001, the feedback the company received was that security in the cloud was a major concern and processing credit card transactions in the cloud was perceived as impossible due to the lack of AWS’s PCI DSS certification. Amazon addressed those gaps and then saw huge opportunities to work with the government. The big showstopper for the government projects was the lack of government-related certifications for regulations like FIPS and FedRAMP. Amazon lets the customer demand drive its investments in auditing and compliance.

Summary

There are many regulations and laws that architects and product owners must be aware of before building cloud-based solutions. Knowing the audit requirements up front allows the product team to prioritize tasks along the roadmap so that security, privacy, and other regulatory requirements can be built into the system early on instead of bolted on at the tail end. Awareness of these requirements should create the awareness of the need to design strategies around security, logging, monitoring, SLA management, disaster recovery, and other critical components of a compliant cloud service.

References

Alert Logic, Inc. (2013). “Targeted Attacks and Opportunistic Hacks.” State of Cloud Security Report. Spring 2003. Houston.

Aws.amazon.com (2010, December). “December 2010: PCI Compliance and ISO 27001 Certification, Amazon Route 53, Free EC2 Monitoring, GPU Clusters, and More.” Retrieved from http://aws.amazon.com/about-aws/newsletters/2010/12/15/december-2010—-pci-compliance-and-iso27001-certification/.

AWS.amazon.com (2013). “AWS Achieves FedRAMP Compliance.” Retrieved from http://aws.amazon.com/about-aws/whats-new/2013/05/20/aws-achieves-fedramp-compliance/.

Carsaretto, J. (2013, May 17). “Amazon Web Services and Compliance Conversation; SOC 3 Reports Arrive.” Retrieved from http://siliconangle.com/blog/2013/05/17/amazon-web-services-starts-the-security-and-compliance-conversation-soc-3-reports-arrive/.

Clark, J. (2012, June 7). “How Amazon Exposed Its Guts: The History of AWS’s EC2.” Retrieved from http://www.zdnet.com/how-amazon-exposed-its-guts-the-history-of-awss-ec2–3040155310/.