Understanding cloud auditing

As companies look for ways to lower costs, increase efficiency, and enable remote and distributed workforces, the expansion and adoption of cloud subscription-based services continue to grow. Along with that growth, there’s a need to make sure the IT controls for a company have been reviewed, adapted, and adequately applied and assessed to address the criticality of cloud services used as part of the IT ecosystem.

With cloud environments, several different types of auditing exist. A cloud service provider (CSP) may want to provide a certification to its customers regarding its defined and operating controls through a System and Organization Controls 2 (SOC 2). Other companies may want to certify that their environments meet International Organization for Standardization (ISO) or National Institute of Standards and Technology (NIST) standards or implement controls according to a given compliance framework, such as Payment Card Industry (PCI) compliance. In this book, we will focus on auditing a CSP customer environment from a general IT computing perspective.

Whether you are performing as an internal or external auditor within a cloud customer (enterprise) environment, it’s important for you to understand how an IT computing control that’s traditionally been applied against an on-premise environment may still be relevant. However, it will require adjustments to your testing procedures when validating them in a cloud environment. An example of this would be PCI Data Security Standard (PCI DSS) controls requiring organizations to establish and maintain a detailed enterprise asset inventory. The dynamic nature of cloud environments and the speed and scale at which new assets can be provisioned can make this a challenge. In this instance, not only should an enterprise IT auditor be aware of whether this inventory exists and covers all enterprise assets to ensure they have effective control coverage, but they should also be aware of the processes around billing and financial management within the cloud, how change management and resource allocation are performed, and which users have administrative rights to these functions. In some cases, you may need to consider how the control has to support the effective operations of a multi-cloud environment and the ability across cloud provider platforms to satisfy a particular control. The ability to categorize and quantify risks related to the use and integration of cloud services into an organization’s business processes is quickly becoming an essential skill for auditors.

Shared responsibility of IT cloud controls

When planning and executing an audit, it is critical to understand cloud shared responsibility (and in the case of Google Cloud Platform (GCP), “shared fate”) model agreements with CSPs whose services have been integrated into the customer environment in scope to be audited. The intent of the shared responsibility model agreements is to provide clear guidance on the security, controls, and obligations to compliance that the CSP is responsible for, and what the cloud consumer/customer will need to take responsibility for. Anytime you have a cloud-based component as part of your business operations, it is important that you understand the shared responsibility model with that CSP. In general, shared responsibility simply means there are actions, tools, processes, capabilities, and controls that the CSP is responsible for and others that the cloud customer will be responsible for, and some that require joint responsibility for full control coverage. An example of this would be in the case of NIST Cybersecurity Framework control RS.CO.1: Personnel know their role and order of operations when a response is needed. In a traditional on-premise environment where the company owns and manages all parts of the infrastructure, understanding who has responsibility for this control and testing compliance of the control would likely be very straightforward. In cloud environments, and especially in multi-cloud or hybrid environments, assessing this control becomes much more complex.

Role of an IT auditor

Shared responsibility agreements help with understanding what information or test evidence may need to be obtained directly from the CSP, which areas the CSP expects the customer to have controls for, and which areas carry a joint responsibility for defining and implementing security controls and protections. In particular, the last two areas should be a primary focus for an IT auditor to understand which risks the customer (enterprise) has elected to accept or address, through security or configuration controls, and build an audit plan that assesses the effectiveness of those controls. In most cases, it will be helpful (and potentially required) for the IT auditor to obtain an assurance report from the CSP, with SOC 2 Type 2 reports being a common report from the CSP that provides a “qualified opinion”, based on an independent audit, of the effectiveness of the operating controls for which the CSP has taken responsibility. The report can be used to identify deficiencies in testing and control coverage that need to be addressed for the customer (enterprise) environment. A SOC 2 Type 2 report is based on “trust service principles” defined by the American Institute of Certified Public Accountants (AICPA). These principles cover the categories of security, privacy, confidentiality, integrity, and availability for the CSP environment. An independent assessor determines if the CSP complies with one or more of the five trust principles and issues a report attesting to the operating effectiveness of the control over a given time period (generally 12 months). Based on the business practices of the organization undergoing a SOC 2 assessment, the content of the report may vary. Each organization can design its own control(s) to adhere to one or all of the trust service principles. As an enterprise IT auditor, you will be responsible for reviewing and understanding the “qualified opinion” on the SOC report, as well as closely reviewing the scope of which trust principles have been covered and the time period of testing. Additionally, organizations undergoing a SOC 2 compliance review may elect not to perform additional procedures to mitigate any residual risks for gaps identified in the SOC report or for trust principle areas for which they have elected to not have controls. You will need to review and support your organization in discerning if there is an effective level of coverage. You should also note that SOC 2 Type 2 reports may not be acceptable for some international companies. For example, some international companies in Europe prefer ISO 27001. Your auditing procedures and review of shared responsibility need to take into account the regions for which the cloud environment has been deployed, the business usage and types of applications that will be supported, and the data protections required across the regions. Consideration also needs to be taken regarding the timing of received assurance reports. Depending upon your organization’s audit cycle, there may be a gap in the timing coverage of the CSP’s standard assurance report made available to all of its customers, and the audit period and requirements of your organization for when control is to be tested. In this case, you will need to obtain a bridge report that provides an attestation of control effectiveness during the gap period.

When operating within a multi-cloud environment, there are likely to be many similarities in the cloud shared responsibility model across cloud providers; however, each agreement should be reviewed independently and assessed as part of an end-to-end review of control coverage for every relevant process executing through the cloud environment. Additionally, the responsibilities between the CSP and cloud customer may differ depending upon the vendors, services, and deployment models used, requiring the auditor to be aware of the complete architecture of the customer’s cloud environment, the services being consumed, and how those services relate back to business and IT operations. Additional resources on shared responsibility with the three major CSPs can be found in the following list:

• Shared Responsibility Model, Amazon Web Services (AWS) Elastic Compute Cloud (EC2): https://aws.amazon.com/compliance/shared-responsibility-model/
• Shared Responsibility Model, Microsoft Azure: https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• Shared Responsibility Model, GCP: https://cloud.google.com/blog/products/identity-security/google-cloud-security-foundations-guide
• Cloud Security Alliance explains shared responsibility: https://cloudsecurityalliance.org/blog/2020/08/26/shared-responsibility-model-explained/

Now that we discussed the types of cloud auditing covered in this book and now understand the shared responsibility between cloud providers and the cloud customer to implement IT controls, we have begun to build our foundation for applying best practices in cloud auditing. To further build your cloud foundation, we will now review cloud architecture and service models and the impact they have on cloud auditing.