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.

As an IT auditor, it is important to be aware of the cloud architectural and deployment design changes that have been made and that influence operations within the IT environment being audited. Knowing how cloud services have been enabled and integrated with business operations is key to validating the scope of compliance testing and potential exposure related to risk.

Understanding gaps or weaknesses within the architecture and design of a cloud environment is essential to providing guidance on where there may be breakdowns of the confidentiality, integrity, or availability (CIA) business goals of an organization. Providing a technical understanding of how to identify these gaps and which technical or non-technical solutions exist for mitigation or remediation is one of the goals of this book. The cloud architecture and deployment choices may not have only impacted the technology in use, but may have also impacted which employees may be maintaining a given service on-premise versus within the cloud, and thus impact who would need to be contacted for walk-through interviews, architectural diagrams, and evidence gathering. For example, the employees responsible for managing on-premise network configuration may be different than those who manage the virtual configuration within the cloud environment.

It may have also impacted the legal and regulatory compliance an organization must meet and how those obligations should now be tested. In the previous example, where separate employees are now responsible for maintaining network infrastructure based upon where it is done, understanding this separation of responsibility may also be a factor in effectively assessing the separation of duties (SoD) as well as identity and access control policies throughout the environment. Determining if the business operates within a hybrid (using both on-premise and cloud-based services), single-cloud, or multi-cloud environment has direct implications on the audit program, risks to be assessed, testing steps, and testing evidence that needs to be produced. For companies that have an existing legacy environment and are migrating to the cloud, or may be operating in a hybrid landscape, identifying which service models are in use will help in validating existing controls are still applicable (given the cloud shared responsibility model), and if so, are being tested thoroughly and within the right technologies.

To prepare you to apply best practices in auditing various types of cloud configurations, we will now review cloud architectures, and next, we will look at cloud services. We will close out the chapter with information on how to navigate within the three main cloud providers.

Cloud architecture

There are an infinite number of variations on how a company may choose to implement its cloud environment, and each may have nuances to consider when performing an audit assessment; however, we will focus on the most important general concepts you will encounter and need to know to build a good foundation concerning cloud architecture. Let’s find out what they are in the following sections.

Public and private cloud deployments

A company may choose to operate within either a public or private cloud environment, or even have some combination of the two, depending upon their business, operational, security, and/or compliance requirements. With a public cloud deployment, the company has chosen to use services from a CSP, where the CSP is managing the physical infrastructure in a location that is owned/managed by the CSP. In the case of a private cloud deployment, the infrastructure may be managed both on-premise at the customer’s location or by a third-party CSP. A private cloud restricts the use of the infrastructure to a single company or organization.

Hybrid cloud environments

Considering there are companies that have been around much longer than the concept of cloud computing has been in existence, it can be expected that there are a large number of organizations operating in environments that use a combination of on-premise and cloud IT technologies. This may be due to the complexity of migrating all their legacy functionality to the cloud, or there may be legal, compliance, security, or data sensitivity reasons. Referring to the information we covered on the shared responsibility agreements between CSPs and customers, the customer may have chosen not to accept the risk related to moving certain applications or workloads into a cloud system. Having the context of why the customer is operating within a hybrid environment is highly relevant to understanding which security and data controls should be in place to maintain the separation, assessing the effectiveness of controls that have been put in place to protect boundaries, and understanding and articulating the risk if boundaries have been crossed as part of the use or integration of a particular cloud service.

Cloud-native/cloud-first environments

Some companies have chosen to adopt a technology philosophy of only using solutions that are built in the cloud and specifically for cloud environments. In this type of architecture, it comes critical to have reliance on third-party audits (such as SOC 2), the time period and cycle of such audits, and the assessment of where gaps may exist between the third-party-assessed controls of the cloud provider compared to the controls that the customer requires.

Multi-cloud environments

As companies utilize more cloud services, it is becoming increasingly common to find architectures that are based on multi-cloud environments. Having a multi-cloud environment means the company is leveraging one or more service models from at least two different cloud providers. In some cases, this may be to take advantage of the best-in-class features of a given CSP, or it may be to support redundancy or other business operational requirements. In assessing multi-cloud environments, the auditor should have familiarity with each of the cloud platforms as well as an understanding of any integration occurring between them. Now that we have learned about forms of cloud architecture and their impact on auditing, we will now look at the various types of cloud services.

Cloud services

In general, there are three cloud service models covered in the following list. This book will focus on the first two:

• Infrastructure as a Service (IaaS): In this service model, the cloud customer manages the virtual compute, storage, and network resources through a portal (also known as a management plane), or through APIs with the CSP. The customer is not responsible for securing the underlying physical hardware but is responsible for the operating systems and software running within this service. As an auditor, some key testing and control questions to ask could include the following:
  • Who has access to the management plane to administer the infrastructure resources?
  • Who has access to the administration APIs?
  • Which images are being used, and do they adhere to company policies and standards?
  • What is the backup strategy being used for the infrastructure?
  • What is the process used for maintaining patching?
• Platform as a Service (PaaS): In this service model, the CSP manages the hosting environment, services, and tools, and the customer creates, manages, and deploys the applications running within the environment. The CSP is generally responsible for both the physical and virtual infrastructure security and maintenance. As an auditor, some key testing and control questions to ask might include those previously shown, as well as the following:
  • What is the process for reviewing and managing changes by the CSP as part of periodic updates and patches it may be applying?
  • Who has access, and what is the process to deploy a new application?
  • Is this application internal- or external-facing? What are the network controls surrounding who can get to this application?
• Software as a Service (SaaS): With this service model, the customer is interacting with an application that has been built and provided by the CSP. This application may be hosted with the CSP or with another third party; however, responsibility for the security and configuration of the entire underlying infrastructure is generally the responsibility of the CSP. In this instance, some key testing and control questions an auditory may ask could include the following:
  • Which data does this application have access to?
  • How is this application integrated through APIs and other methods into other parts of the IT environment?
  • Who is responsible for managing users and the user life cycle regarding access to this application?

In the previous sections, we covered some foundational information about the architecture of cloud environments and the types of cloud services that you as an auditor may find as you begin to perform an IT general computing controls audit. As a final step in building your foundational toolkit and preparing to learn auditing best practices, we’ll next look at how to perform basic navigation to a cloud environment.

To effectively audit an IaaS or PaaS deployment for any of the three major cloud providers, it is important to understand basic navigational components within those platforms. In this section, we will gain a basic understanding of fundamental navigation within AWS EC2, GCP, and Microsoft Azure.

Cloud platforms and services are inherently dynamic, and this is one of the benefits of leveraging a cloud service. With that in mind, the navigational components within a cloud environment do change, including the renaming of components and services. The navigation structure presented in this section is what exists as of the time of this writing. We will focus primarily on the use of the web-based console for accessing and navigating components within the cloud environments.

Note that each of the cloud providers leverages role-based access control (RBAC). This means that the content you can access and view or maintains is based upon the access that has been granted to your account. To become more familiar with navigation within the cloud providers, I encourage you to set up a free account that you can use for training and development purposes to view the full breadth and depth of cloud services from an administrator’s perspective.

Navigating Amazon AWS EC2

To enter the AWS management console, we will begin at the following URL: console.aws.amazon.com.

Depending upon your organization’s identity and access management (IAM) integration and customizations, you may have an organization-specific URL to use and additional authentication procedures. For new and/or uncustomized AWS deployments, you will be routed to a sign-in page similar to what is shown in the following screenshot:

Figure 1.1 – AWS console initial sign-in

Upon successful authentication, depending upon the roles and permissions granted to your account, you will find a Console Home page, as shown in Figure 1.2. Please note that depending upon the region selected when the cloud provider relationship was established, the region that appears within your URL after sign-in may differ. The AWS Console Home page is made up of various widgets, and this home page is customizable, meaning the widgets may be removed and other widgets added. On the left top panel of the AWS Console Home page, you will see a Services option:

Figure 1.2 – AWS Console Home main page

Within the Services option, you will find a navigable list of various AWS service groupings. Clicking on hyperlinked items within the Services list will present an additional list of options aligned with those service groupings or categories:

Figure 1.3 – AWS Console Home Services list

On the right side of the Console Home page, you will find a drop-down option available under the account login that will display Account ID information, as well as additional information related to the Organization, Billing Dashboard, and Security credentials configuration, and Settings. Let’s see how that looks in the following screenshot:

Figure 1.4 – AWS Console Home account sign-In details

Within the main body of the Console Home page, you will find widgets available for learning more about AWS, the health status of your AWS environment, and direct links to AWS cloud services:

Figure 1.5 – AWS Console Home widgets

Now that you’ve learned how to successfully sign in to the AWS console, understand the items that you may see within the Console Home page, how to navigate and find a list of services within AWS, and understand that customizable sections of the home page in AWS are known as widgets, let’s take a look at navigating within the Microsoft Azure portal.

Navigating the Microsoft Azure portal

To enter the Microsoft Azure management console, we can begin at the following URLs: portal.azure.com or azure.microsoft.com.

Depending upon your organization’s IAM integration and customizations, you may have an organization-specific URL to use and additional authentication procedures. Let’s take a look at what your initial sign-in experience in Azure may look like in the following screenshot:

Figure 1.6 – Microsoft Azure initial sign-in

The Azure portal home page is made up of various blades, and depending upon your organization’s configuration, your initial entry into the portal may look similar to what’s in the following screenshot, which shows a list of services along with a panel of recent resources that have been accessed:


Figure 1.7 – Microsoft Azure portal home page

On the left panel, you will find a drop-down menu that will allow you to navigate to a dashboard or a list of services and resources:

Figure 1.8 – Microsoft Azure portal home page navigation panel

Additionally, you will find options under the Navigate section, which are Subscriptions, Resource groups, All resources, and Dashboard, in the middle of the home page pane, as follows:

Figure 1.9 – Microsoft Azure portal dashboard Navigate section

When navigating to Dashboard, you may have a list of private or organizational-level dashboards that have been made available to you, and these dashboards may be customizable:

Figure 1.10 – Microsoft Azure portal personal dashboard

On the top right of the Azure portal home page, you may find additional information about your account, or you can switch the Azure portal directory you are logged in to, assuming you have additional accounts and permissions. To learn more about where these options appear, let’s take a look at the following screenshot:

Figure 1.11 – Microsoft Azure portal sign-in details

Additional information you may be able to access in this section, depending upon your roles and permissions, includes permissions assigned to you, billing details for the Azure account, and contact information associated with your account:

Figure 1.12 – Microsoft Azure portal account details

You are now well on your way to a great understanding of navigating within the three major cloud providers. We’ve walked through how to navigate in both AWS and Azure, and now let’s look at the final cloud provider we will be learning to navigate—GCP.

Navigating GCP

To enter the GCP management console, we can begin at the following URL: console.cloud.google.com.

Depending upon your organization’s IAM integration and customizations, you may have an organization-specific URL to use and additional authentication procedures, but the home page should look something like this:

Figure 1.13 – GCP home page

The GCP home page is made up of various cards, and depending upon your organization’s configuration, your initial entry into the portal may look like what’s seen in Figure 1.14, with a list of cards displaying available resources and status, along with an open panel of pinned and available products and resources that have recently been accessed:

Figure 1.14 – GCP home page dashboard

We’ve covered a lot in this section that will help you with successfully navigating to and within each of the three major cloud provider platforms—AWS, Microsoft Azure, and GCP. For each of these providers, we’ve learned about starting URLs that may be used to sign in, what an initial home page or dashboard may look like, and some of the terminology associated with navigating within each of these providers. Our foundational toolkit is now complete!

In this chapter, we have reviewed the concept of cloud auditing and the importance of understanding the concept of cloud shared responsibility models and how those may differ across cloud providers, cloud deployment models, and cloud services. We have also looked at general concepts to be aware of related to cloud architecture, deployment, and service models and how this may impact the risk and compliance assessments for an organization. Finally, we reviewed fundamental concepts around the basic structure and navigation within each of the three major cloud platforms covered in this book (AWS, Azure, and GCP).

Knowing these foundational concepts will establish the primary tools you need to begin deeper learning on the best practices of cloud auditing, allowing you to define a list of cloud and IT security controls to be considered, identify IAM controls that are in place, and utilize policy and automation for your audits.

Now that we have reviewed these core concepts of cloud environments, in the next chapter, we’ll begin identifying effective techniques for preparing to audit cloud environments.