Trust, but verify.

—Russian proverb

You may recall this quote from President Ronald Reagan (during nuclear disarmament discussions with the Soviet Union), but this Russian proverb is truer today than ever with regard to cloud services. Providers will supply you with all sorts of documentation to build trust in an offering, but how are the security statements within these documents verified to ensure that you remain compliant with regulations that affect your company? The reality is that you’re likely dealing with third-party audits with regard to the verify portion of this proverb.

The virtualized and distributed nature of the cloud forces customers to understand and appreciate jurisdictional differences and their implications on existing compliance and audit standards, processes, and practices that aren’t faced in the traditional data center environment.

Auditors need to adjust to the virtual world that is cloud computing. Regulations aren’t written specifically to address cloud environments, just as they aren’t written specifically for a particular programming language or operating system to run applications that fall under regulatory focus. Regulatory bodies such as NIST and ISO have created cloud-specific guidance and/or control frameworks to try to fill the gap between traditional and cloud deployments. Your understanding of the compliance challenges in a cloud environment is paramount, and these challenges need consideration when you’re developing a cloud strategy.

Following are some compliance items that you should consider as part of your cloud implementation:

•   Jurisdictional issues Your company may face regulations that forbid the export of data to foreign jurisdictions.

•   Shared responsibility model inherent with all types of cloud services Remember that shared responsibility will be highly dependent on the service model being consumed (Software as a Service [SaaS], Platform as a Service [PaaS], or Infrastructure as a Service [IaaS]).

•   Compliance inheritance Consider PCI, for example. The IaaS provider you use to host a credit card processing system may be Payment Card Industry (PCI) Level 1 certified, but your application must meet all other PCI requirements as well.

•   Supply chain complexity Consider the complexity of the supply chain. For example, many SaaS providers of all sizes may themselves use an outsourced IaaS solution to store customer data, or SaaS providers that leverage multiple PaaS providers may in turn use different IaaS providers.

•   Artifacts of compliance from the provider All the artifacts of compliance (such as system logs) that you require for traditional systems will still be required in a cloud environment. The real question is whether you can obtain these artifacts and do so in a timely manner.

•   Scope relevance Are the features and services of a cloud provider within the scope of your previously performed audits and assessments?

•   Compliance management How does the provider manage compliance and audits—not just now, but over time as well?

•   Audit performance How are audits of cloud computing performed compared to those in a traditional data center environment?

•   Provider experience Does the provider have experience working with regulatory bodies?

This chapter covers two related subjects: compliance and audits. Each section contains backgrounder information on the subject material, since not all readers will have an appreciation of these functions. This information sets the stage for a discussion on how these functions change as a result of cloud technologies.

Compliance Backgrounder

Compliance generally means conformance to regulations, laws, policies, standards, best practices, and contracts. It is an important part of GRC (governance, risk, and compliance) that enables proper oversight of computing—and cloud computing is no different. A compliance framework is the set of policies, procedures, processes, and technologies implemented by an organization to identify and adhere to applicable requirements based on laws, regulations, and standards. Compliance also involves an assessment of the costs of noncompliance and can act to prioritize and fund compliance initiatives. Compliance is both expensive and mandatory, but the costs associated with noncompliance could be devastating to a company, and executives in a company charged with noncompliance could face jail time as a result.

As mentioned, compliance works in conjunction with governance and risk management to create GRC. To help you understand how compliance fits in, I’m going to stick with the following flow: Governance considers the corporate obligations (from laws and regulations, to protecting the interests of stakeholders and shareholders, corporate ethics, and social responsibilities) that determine how a company operates. Governance helps the company form and manage its risk tolerance. This then feeds risk management to implement the required controls to address both regulations and risk tolerance. Compliance then uses audits to ensure that appropriate controls are indeed in place.

I like to use the Deming cycle—Plan, Do, Check, Act (PDCA)—to show relationships within the risk management spectrum. (This well-known “continuous quality improvement model” was developed by W. Edwards Deming in the 1950s.) Here is a simplified list of these phases in GRC terms:

•   Plan Determine what regulations are in scope and what controls need to be addressed as a result.

•   Do Implement the required controls.

•   Check Perform audits to ensure that required controls meet the requirements.

•   Act Fix any deficiencies and provide feedback to future improvements.

The concepts of compliance and associated auditing don’t change as a result of using cloud services. After all, a cloud service provider (CSP) is just another third party, and you most likely have some form of a third-party oversight program in place. There are, however, specific compliance items that you need to consider for cloud implementations, which are covered in the following sections.

Impact of the Cloud on Contracts

When examining contracts and service agreements between your organization and cloud service providers, you should focus on the following items:

•   Security service level agreements The importance of security SLAs is often overlooked when reviewing CSP contracts. Following is a nonexhaustive list of the key items you should look for as part of a security SLA with a cloud provider:

•   Specific written compliance commitments for standards that apply to your organization

•   Service level commitments and liability terms for a data breach

•   Exposure of detailed security monitoring for your organization’s implementation

•   Explicit descriptions of security implementations and commitment to compliance

•   Ownership of data Believe it or not, some cloud providers have clauses in their contracts that transfer ownership of any data uploaded by a customer to the provider. In turn, the customer gets unlimited access to this data, but the provider is allowed to do whatever they please with said data, including retaining it upon contract termination and/or selling it to others. This is more common with “free” versions of SaaS products.

•   Right to audit You may see this referred to as a “first-party audit.” Essentially, this is a contractual clause that allows the customer to examine the supplier’s premises and systems upon reasonable notice. You may see this clause in an SLA if the provider sees a reason to take extreme measures to get your business. The reality is that big providers almost never grant this ability to customers.

•   Third-party audits This clause requires the provider to undergo appropriate and regular audits. Reports from these audits should be made available to customers upon request. The reports should also include remediation plans for any significant issues identified in the reports.

•   Conformance to security policies You need to understand the security policies in place at the cloud provider and understand how they meet your particular policy requirements. In the likely event that a service provider contract does not fully address your policies, you need to fill the gaps with your own controls.

•   Compliance with laws and regulations Contract clauses should clearly state that the service provider conforms to all relevant laws and regulations that are important to your organization. For example, if you are looking to store healthcare information in a particular provider’s environment, you must ensure that the provider is contractually bound to remain compliant with HIPAA regulations.

•   Incident notification You should understand how incidents are declared and how customers are notified by the provider (and vice versa) of incidents. Notifications could be required for service changes, interruptions, and, of course, security incidents. Specific time periods should be stated in the contract for these notifications.

•   Liabilities Liabilities clauses should clearly state which parties are liable for which actions and activities. Available remedies should also be listed should either party fail to perform adequately.

•   Termination terms The contract should contain provisions that describe the actions a CSP will perform if the business relationship is terminated. For example, how will customer data be deleted when a customer leaves, and in what time frame?

In addition to these items, you should investigate a couple of other items that are not cloud specific:

•   Service levels Understand the CSP’s acceptable service levels and the processes that are followed in the event of service interruptions. Is there an escalation path for notifications, or does the provider supply clients with a status update web site? In the event of a widespread outage, a CSP will likely use a status update page to update customers on outages or system-wide issues. Another aspect you need to understand is that many cloud providers will give customers only “service credits” as a form of penalty if unavailability is in excess of stated availability agreements (generally 99.9 percent uptime). And some providers will issue these credits only if the customer makes a claim for credits and shows the provider evidence of the outage.

•   Quality levels What remedies are in place if quality standards, such as following best practices and quality control procedures, are not met by the provider? You need to remember that operational procedures performed by the cloud provider in a cloud environment have a direct impact on your company’s ability to operate in that environment.

How the Cloud Changes Compliance

The two biggest terms to remember about compliance in a cloud environment are “compliance inheritance” and “continuous.” The following sections discuss both topics.

Compliance Inheritance

Going back to the logical model from Chapter 1, infrastructure in particular, you already know that this is completely under the control of the public cloud provider, and you most likely won’t have access to audit that environment. So what’s a company to do to prove compliance?

Use of third-party audit results (such as those discussed in Chapter 2 and later in this chapter), called “pass-through audits” by the CSA, is a form of compliance inheritance. In this case, you basically confirm that a provider is compliant with the areas for which they are responsible via vendor-supplied audit results or certifications, and then you ensure that your systems running in the cloud environment are also compliant. This is the core of the shared responsibility model discussed in previous chapters.

Consider an example, such as that shown in Figure 4-1, in which you build a credit card processing application on top of a Windows server that doesn’t have any form of malware inspection. (Congratulations! You just failed to meet PCI DSS 5.3!) The provider gave you a “PCI DSS Level 1” environment in which to operate your application, and yet you still blew it. This is the shared responsibility model in action. The provider is responsible for the facilities and the hardware, and your organization is responsible for configuring the server instance, the application, and any required logical security controls.

Figure 4-1   Compliance inheritance. (Used with permission of Cloud Security Alliance.)

Continuous Compliance

I want to take a moment to make a distinction here between continuous monitoring and continuous auditing. Although they are often considered joint activities (some refer to it as CM/CA), they really aren’t the same thing. One commonality they share is that “continuous” doesn’t necessarily mean real-time analysis. NIST defines Information Security Continuous Monitoring (ISCM) thusly: “Security controls and organizational risks are assessed and analyzed at a frequency sufficient to support risk-based security decisions to adequately protect organization information.” On the other hand, ISACA (formerly known as Information Systems Audit and Control Association) calls out the distinction between a “traditional” and a “continuous” audit as a short time lapse between the facts to be audited, the collection of evidence, and audit reporting. Techniques to perform continuous auditing are referred to as computer-assisted audit techniques. The bottom line is that “continuous” does not mean real-time 24×7×365. It addresses performing something at an appropriate frequency, and that is up to the system owner.

Now that I have addressed the term “continuous” and what it means according to organizations such as NIST and ISACA, let’s turn our focus to the cloud and see what the CSA has to say on the subject. The guidance itself is fairly limited in coverage, as the only reference to continuous compliance, audit, and assurance is the following:

Compliance, audit, and assurance should be continuous. They should not be seen as merely point-in-time activities, and many standards and regulations are moving more towards this model. This is especially true in cloud computing, where both the provider and customer tend to be in more-constant flux and are rarely ever in a static state.

In other words, there’s a requirement to be up-to-date continuously with any changes made at the provider’s side (in addition to your changes, of course) that may impact compliance. So, for example, if your provider moves its data center jurisdiction and your data is now noncompliant with a government regulation, you need to know about this as soon as realistically possible.

Beyond the guidance, however, the CSA has done a lot of work on its continuous compliance assessment program and has made it part of the STAR registry, which was covered back in Chapter 1. The goal of the STAR Continuous is to address the security posture of cloud providers between point-in-time audits. When you adopt STAR’s continuous auditing with an increased audit frequency, the chances of deviation of the provider’s security posture become lower, and customers can have better validation of a provider with an “always up-to-date” compliance status.

That’s great and all, but how do providers address this continuous compliance initiative? Automation, that’s how! Remember that cloud environments are automated environments to begin with, so why can’t testing of the environment be automated as well and be executed by the provider at an expected testing frequency between the point-in-time audits they currently provide to customers? Of course, not everything can be automated, so additional manual activities will have to be performed as well, but through the use of this STAR Continuous approach, customers will be able to have greater confidence in the security controls in the provider’s environment.

Finally, the cloud may also change compliance by the introduction of a global network at your disposal. As you know, all jurisdictions have their own laws and regulations that may cause regulatory issues for your firm if sensitive data is accidentally placed in, or moved to, a different jurisdiction. Additional compliance challenges may arise because not all services and regions offered by a provider may have undergone the same audits and attestations.

Audit Backgrounder

In CISA Certified Information Systems Auditor All-in-One Exam Guide, Fourth Edition (McGraw-Hill, 2020), author Peter Gregory defines audit as “a systematic and repeatable process where a competent and independent professional evaluates one or more controls, interviews personnel, obtains and analyzes evidence, and develops a written opinion on the effectiveness of controls.” Alternatively, ISO 19011:2018 defines audit as a “systematic, independent and documented process for obtaining audit evidence [records, statements of fact, or other information that is relevant and verifiable] and evaluating it objectively to determine the extent to which the audit criteria [a set of policies, procedures, or requirements] are fulfilled.” As you can see, there is commonality across multiple organizations as to how an audit is defined. Some key takeaways need to be mentioned:

•   First are the terms “systematic” and “repeatable.” This requires that a methodology/standard be followed. This will be driven as part of the audit management function. I discuss audit management in the next section of the chapter.

•   Second, a key term regarding audits is “independent.” Audits must be independently conducted and should be robustly designed to reflect best practices, appropriate resources, and tested protocols and standards. Naturally, you may have concerns regarding the true independence of an auditor, or the firm itself if they are being paid by the cloud provider. In this case, you need to place your trust in the audit firm as being a true independent source.

Audits generally include some form of testing. The two types of testing are compliance testing and substantive testing. Compliance testing is used to determine whether controls have been properly designed and implemented. This type of testing would also include tests to determine whether the controls are operating properly. Substantive testing, on the other hand, looks at the accuracy and integrity of transactions that go through processes and information systems. In general, you’ll likely be relying on previously performed audits that have used compliance testing.

Audit Management in the Cloud

Most organizations are subject to a mix of internal and external audits and assessments to assure compliance with internal and external requirements. Audit reports include a compliance determination as well as a list of identified issues, and they may contain remediation recommendations. Information security audits and assessments typically focus on evaluating the effectiveness of security management and controls.

Audit management ensures that audit directives are implemented properly. This function includes determining appropriate requirements, scope, scheduling, and responsibilities. Audit management uses compliance requirements and risk data to scope, plan, and prioritize audit engagements.

Audits are planned events, and planning audits is part of the audit management function. Audit planning includes several stages. It is very important for you to note that audits of both a CSP’s and your company’s usage of the cloud will be required. Much of the auditing of a CSP will consist of third-party audit reviews that won’t require the same planning as regular audits, as you will be consuming audit reports, not creating them. However, from the perspective of an internal use of a cloud audit, general audit management principles will remain, but you will require highly specialized resources who understand the new cloud-specific technologies (such as containers and serverless technologies) that may be associated with your deployments.

For audit planning, consider the following when creating audit schedules and assigning resources for audits of cloud environments:

•   Purpose What is the goal of the audit? Is it to determine compliance with a particular law, standard, contractual obligation, or internal requirement that has been introduced or changed? It is an initial audit of a service provider to determine appropriateness of use, or is it intended to determine whether a previously discovered deficiency has been remediated?

•   Scope This is the most critical aspect when consuming cloud services. All certifications and audit results supplied by a provider will have a specific scope. Scope can be based on specific services, geography, technology, business processes, or even a segment of the organization. You must understand the scope of an audit report and compare it to what you are actually consuming.

•   Risk analysis This is another area that is directly related to cloud services. What cloud services pose the highest level of risk to your organization based on the criticality of the data being stored in a particular environment? This will ultimately determine the frequency and depth of audits that need to be performed against the wide array of cloud services your company is presently using or will be using in the future. Always remember that this isn’t just a provider issue. You will need to audit your implementation as well in the shared responsibility model of the cloud.

•   Audit procedures The procedures are the rules and processes defined in the audit methodology and/or standard. Compliance audits may determine the procedures that should be followed and the qualifications of the auditor. Audits of cloud environments should be performed by auditors with knowledge of cloud environments.

•   Resources The resources that need to be identified include the time that should be allocated for performance of the audit and the tools that will be required to execute the audit. For a cloud environment that exposes a programmatic interface such as CLIs or APIs, the tools may be developed so they are highly repeatable.

•   Schedule An audit schedule should be developed that gives the auditor an appropriate amount of time to perform interviews, collect and analyze data, and generate audit reports. The time it takes to perform the audit will depend on multiple factors, such as the size of the scope, the applicable controls (ISO calls this the “Statement of Applicability”), and the complexity of the environment. This can be accelerated for the cloud because your auditors will likely be reviewing third-party audits. Alternatively, determining how often point-in-time audits should be performed can also be considered a function of audit management.

SOC Reports and ISO Certifications Backgrounder

Most CSPs will use two primary audit standards to demonstrate that appropriate security is in place for their cloud services: Service Organization Control (SOC) and International Standards Organization (ISO) standards. I’m covering these to increase your understanding of the standards themselves. You won’t be tested on the contents of either SOC reports or ISO certifications as part of your CCSK exam, but if you’re going to be working in a cloud environment, you should know what the standards are and how they differ.

SOC Backgrounder

Although I covered the SOC report levels and types in Chapter 2 (quick reminder: SOC 1 is for financial reporting, SOC 2 is for security controls, Type 1 is a point-in-time look at control design, and Type 2 looks at operating effectiveness of controls over a period of time), you should understand a few more items before reviewing the SOC 2 reports supplied by your providers. The areas covered here include the definitions of terms associated with a system, the various Trust Services Criteria (TSC, formerly known as Trust Services Principles and Criteria), and some associated control categories.

Let’s begin with definitions of terms used to describe a system. According to the AICPA, a system comprises the following components:

•   Infrastructure The physical structures, IT, and other hardware such as facilities, computers, equipment, and networks.

•   Software The application programs and system software, including operating systems, middleware, and utilities.

•   People All personnel involved in the governance, operation, and use of a system. Examples include developers, operators, users, vendor personnel, and managers.

•   Processes Both automatic and manual processes. All processes are included as part of the engagement report.

•   Data The information used or processed by a system.

These terms are all included as part of the attestation engagement report standard by the AICPA and cannot be selected by the management of the CSP when they want to have a particular system undergo an SOC report process.

Next up are what the AICPA defines as the five Trust Services Criteria. Management of the CSP can select the trust services they will attest to. Some providers may include only the security trust service criteria examined by an auditor, while others may include all five in their reports. The trust services and their associated goals from the AICPA are as follows:

•   Security The system is protected against unauthorized access, use, or modification.

•   Availability The system is available for operation and use as committed or agreed to.

•   Confidentiality Information designated as confidential is protected as committed or agreed to.

•   Processing Integrity System processing is complete, valid, accurate, timely, and authorized.

•   Privacy A system’s collection, use, retention, disclosure, and disposal of personal information is in conformance with privacy notices.

Each of these trust services has associated categories and controls (basically defining what a system must do). All of the trust services leverage what the AICPA calls the Common Criteria. Essentially, the Common Criteria consists of seven categories and the control objectives within each category that must be checked. These categories and high-level descriptions are as follows:

•   Organization and Management How the organization is structured and the processes the organization has implemented to manage and support people within its operating units.

•   Communications How the organization communicates its policies, processes, procedures, commitments, and requirements to authorized users and other parties of the system, and the obligations of those parties and users to the effective operation of the system.

•   Risk Management and Design and Implementation of Controls How the entity identifies potential risks that would affect the entity’s ability to achieve its objectives, analyzes those risks, develops responses to those risks including the design and implementation of controls and other risk mitigating actions, and conducts ongoing monitoring of risks and the risk management process.

•   Monitoring of Controls How the entity monitors the system, including the suitability and design and operating effectiveness of the controls, and how the organization takes action to address identified deficiencies.

•   Logical and Physical Access Controls How the organization restricts logical and physical access to the system, provides and removes that access, and prevents unauthorized access to meet the criteria for the trust services addressed in the engagement.

•   Systems Operations How the organization manages the execution of system procedures and detects and mitigates processing deviations, including logical and physical security deviations, to meet the objectives of the trust services addressed in the engagement.

•   Change Management How the organization identifies the need for changes to the system, makes the changes following a controlled change management process, and prevents unauthorized changes from being made to meet the criteria for the trust services addressed in the engagement.

The final thing I think is important for you to know about SOC reports is the concept of Complementary User Entity Controls (CUEC). They’re important because they also drive home the concept of the shared responsibility model of the cloud. These CUECs are contained within the SOC report supplied to customers by the provider to advise customers that certain controls must be in place by the customer to support the SOC report. Some of the more important items to note that will likely be applicable to all cloud services involve logical security. This includes items such as establishing administrators, ensuring that accounts in the system are appropriate and checked on a regular basis, and ensuring that accounts are removed once they are no longer required.

ISO Backgrounder

Now that you understand the structure of the SOC reporting standard and you have a good idea of what you should be looking for when you’re reviewing these reports, let’s move on to the ISO/IEC standards you may encounter when assessing providers.

Following are a few pertinent cybersecurity-related standards that may be promoted by CSPs:

•   ISO/IEC 27001 This standard defines the requirements for an information security management system (ISMS). Note that the entire organization is not necessarily affected by the standard, because it all depends on the scope of the ISMS. The scope could be limited by the provider to one group within an organization, and there is no guarantee that any group outside of the scope has appropriate ISMSs in place. It is up to the auditor to verify that the scope of the engagement is “fit for purpose.” As the customer, you are responsible for determining whether the scope of the certification is relevant for your purposes.

•   ISO/IEC 27002 This standard is a code of practice and serves as a control catalog used in an ISMS. Where the ISO/IEC 27001 standard has an appendix with a list of controls, the ISO/IEC 27002 documentation lists the controls and includes implementation guidance that serve as best practice recommendations. More than 130 controls are included in the 27002 documentation.

•   ISO/IEC 27005 This is the ISO information security risk management guidelines document. This standard is used by organizations to implement information security risk management effectively in compliance with the ISO/IEC 27001 standard.

•   ISO/IEC 27017 This is the set of security controls from ISO/IEC 27002, modified for cloud services, and it adds cloud-specific controls the ISO calls a “cloud service extended control set” that must be addressed. Essentially, this documentation takes all the controls found in ISO/IEC 27002 and adds implementation guidance for both cloud customers and providers.

•   ISO/IEC 27018 This is the code of practice for protection of personal data in the cloud computing environment. Like ISO/IEC 27107, it adds implementation guidance from ISO/IEC 27002 controls applicable to protecting personally identifiable information (PII).

ISO/IEC 27002 controls that support ISMS address security concerns across a wide variety of domains. Although this book doesn’t cover every single control, it includes the areas of focus (security control clauses) that ISO/IEC 27002 does cover, so you can get an idea of the areas checked as part of an ISO certification:

•   Security Policies

•   Organizing Information Security

•   Asset Management

•   Human Resources Security

•   Physical and Environmental Security

•   Communications and Operations Management

•   Access Control

•   Information Systems Acquisition, Development, and Maintenance

•   Information Security Incident Management

•   Business Continuity Management

•   Compliance

The following table breaks down the differences between SOC 2 and ISO/IEC 27001.

How the Cloud Changes Audits

Let’s shift focus to attestations and certifications used when dealing with cloud providers, because you will be reliant mostly on third-party audits. An attestation is a declaration that something exists or is true. Certification is an official document attesting to a status or level of achievement. Both attestations and certifications are based on audit findings. A SOC 2 report is a primary example of an attestation that’s widely used by CSPs. Primary examples of certifications used by CSPs are ISO/IEC 27001 and ISO/IEC 27017 (among others).

Auditing changes dramatically in a cloud environment, because you will most likely be consuming these aforementioned third-party attestations and certifications rather than performing your own audits (remember these will be viewed as a security issue by the provider). In many instances, these attestation reports will be available only under a nondisclosure agreement (NDA). This is the case with SOC 2 reports, for example. This is a condition of the AICPA itself, not the provider.

As you are relying on third-party audits and related attestations and certifications, ensuring the scope of the audit and when the audit was performed are more important than ever. Scope issues you’ll want to address include the data centers, services, and, of course, the controls assessed. All audits and assessments are point-in-time activities. As they say in the financial world, past performance may not be indicative of future results. You always want to obtain the latest attestation or audit report. These reports aren’t released continuously throughout the year, nor are they made available immediately. Don’t be surprised to see that the latest report is actually a few months old. What you are consuming is the result of an audit that was performed during a certain period of time. If you recall from the continuous compliance discussion earlier in this chapter, it is the time gap between audits that CSA STAR attempts to address.

Finally, you know there’s a shared responsibility model at play with the cloud and that it’s not just all about auditing the provider. You will need to collect your own artifacts of compliance to address your organizational compliance requirements. These artifacts of compliance (see the examples shown in Figure 4-2) don’t change as a result of moving to the cloud. What does change is where these artifacts are stored, and how they are controlled may also change. You always want to identify required artifacts and how they can be either generated by your systems or made available by a provider.

Figure 4-2   Artifacts of compliance remain the same in the cloud. (Used with permission of Cloud Security Alliance.)

Right to Audit

With regard to audits of outsourcing providers, it is generally impossible to audit providers unless they have contractually agreed to allow your organization to audit them. This contract clause is known as the right-to-audit clause (aka first-party audit). Without a right-to-audit clause, you will be reliant on published reports such as SOC and ISO/IEC (aka third-party audit). As a CCSK candidate, you must remember that a provider may see auditors in their data center as a security risk. I always imagine thousands of auditors standing in a line that stretches around the outside of the data center, all waiting their turn for access. Now consider the provider with a million customers—would every single one of them have the right to audit? I’m sure you can determine that the result would be mayhem, and that’s why providers generally don’t allow such audits.

Audit Scope

Audit scope takes on a dual intent with concern to cloud services. You have the scope of a third-party audit when dealing with onboarding and maintaining a CSP, and then you have the audit of your usage of a particular cloud service. You need to address a few questions as part of the audit scope when you’re assessing providers. Some of the bigger questions are listed here:

•   What certifications does the cloud service provider have? A SOC 2, Type 2, attestation engagement report will contain detailed information on the system, the tests that were performed, any findings, and management response. On the other hand, an ISO/IEC 27001 certification will generally be a single certification page signed off by the ISO auditor, stating that a part of the organization or the whole organization has obtained its ISO certification for its ISMS and will be good for a period of three years.

•   What services is your company consuming, and are they addressed in the report you have access to?

•   Are there any subservice organizations used by the provider? For example, if you are researching an SaaS that uses an IaaS provider for storing customer data, you need to examine the IaaS provider as well.

Above and beyond the auditing of the service provider, you must also consider the auditing of your organization’s use of cloud services. A good place to start with this is the CUECs discussed earlier in this chapter (in the “SOC Backgrounder” section). These will be focused mainly on metastructure settings, but your audit scope doesn’t end there. Don’t forget compliance inheritance and shared responsibilities that were also covered in this chapter, and remember that artifacts of compliance don’t change; what changes is that the provider may need to produce these artifacts, or may need to allow you to maintain these artifacts. The bottom line for auditing your usage of the cloud is this: you must maintain compliance regardless of where the systems and/or data is held, and this requires you to inspect all facets of your implementations, ranging from the metastructure all the way up to the infostructure layer.

Auditor Requirements

Your company should engage only auditors who have cloud knowledge, such as those who have earned their CCSK. With so many new approaches to implementation in cloud services, the audit function requires an auditor who understands the possibilities available with cloud deployments. For example, consider the concept of immutable servers (covered in Chapter 7), which states that you don’t patch servers; rather, you update an image and replace the vulnerable running server instance with the newly patched server image. An auditor who doesn’t understand this concept may be confused and mark this down as a finding, while in reality, there are many arguments in favor of this approach from a security perspective.

Chapter Review

This chapter addressed compliance and audit management when working with a cloud environment. From a CCSK exam perspective, remember that everything regarding the basics of compliance and audits and why they are performed remains the same in every situation. What changes is who is performing these audits, and that it’s likely to be an independent third-party auditor. Providers will supply customers with third-party (or pass-through) audits, and you need to review these to understand the scope of the engagement and therefore the applicability to your usage of the provider’s offering.

Other items that you should remember for your CCSK exam are as follows:

•   Remember that compliance, audit, and assurance should be continuous, not point-in-time activities. This applies for both customers and providers.

•   Cloud providers should always be as transparent as possible. They should clearly communicate their audit results, certifications, and attestations.

•   Customers should always review audit results provided by providers with particular attention to the services and jurisdictions in the audit scope.

•   Cloud providers must maintain their certifications/attestations over time and proactively communicate any changes in status. Customers must ensure that they are aware of any changes made by the provider that may impact them.

•   Providers should supply customers with commonly needed evidence and artifacts of compliance, such as logs of administrative activity that the customer cannot otherwise collect on their own.

•   Cloud customers should evaluate a provider’s third-party attestations and certifications to support compliance obligations.

•   To avoid potential misunderstanding, customers and providers should engage auditors with experience in cloud computing.

•   When a provider’s artifacts of compliance are insufficient, customers should create and collect their own artifacts. An example of this is adding logging into an application running in a PaaS that doesn’t offer appropriate logging capabilities.

•   Customers should keep a register of cloud providers used, relevant compliance requirements, and current statuses. The CSA Cloud Controls Matrix (see Chapter 1) can support this activity.

Questions

1.   How must audits be conducted?

A.   Always by your company

B.   Always by the provider

C.   Always by an independent auditor

D.   Always by a federal regulator

2.   A pass-through audit is a form of what?

A.   Compliance inheritance

B.   Demonstration of adherence by the provider to industry standards

C.   A physical assessment that has taken place as part of the audit

D.   A term used for all services being in scope for the audit engagement

3.   How do audits work with compliance?

A.   Audits are the technical means to assess systems.

B.   Audits are the processes and procedures used to assess systems.

C.   Audits are a key tool for proving or disproving compliance.

D.   Audits are required for proper governance of cloud systems.

4.   What is true about an attestation?

A.   Attestation is another term for an audit.

B.   Attestation is a legal statement from a third party.

C.   Attestation is testimony in a court of law.

D.   Attestations can be performed only by a CPA.

5.   What is the purpose of audit management?

A.   Manages the frequency of audits

B.   Manages the auditors and their awareness of systems

C.   Manages the scope of audits

D.   Ensures that audit directives are implemented properly

6.   What should you pay particular attention to when reviewing previously performed audit reports given to you by a provider?

A.   The services and jurisdictions in the audit scope

B.   The firm that performed the audit

C.   The date of the audit report

D.   The auditor’s stated opinion

7.   What should a customer do when they cannot collect evidence of compliance on their own?

A.   Tailor the scope of reporting to reflect lack of evidence.

B.   Accept the risk of not demonstrating compliance to regulators.

C.   Evidence not made available to a cloud customer is removed from regulatory oversight.

D.   Such data should be supplied to the customer by the provider.

8.   What is the benefit of continuous compliance to a customer of cloud services?

A.   The customer is supplied with real-time updates to changes in a provider’s environment.

B.   Any changes made to the provider’s environment are supplied within one week.

C.   There are no benefits because customers should only be concerned with a provider being ISO certified.

D.   An increased audit frequency lowers the chance of unknown deviation of security posture in the provider’s environment.

9.   What should a customer do if a provider’s artifacts of compliance are insufficient?

A.   File for a scoping exclusion request.

B.   Create and collect their own artifacts.

C.   Don’t use the provider.

D.   Do nothing.

10.   What can be done to avoid potential confusion when auditing a cloud service provider?

A.   Work with auditors who have their CCSK certification.

B.   Work with auditors supplied by providers.

C.   Work with CPAs.

D.   Work with auditors certified by the Institute of Certified Auditors.

Answers

1.   C. The key concept for audits is that they are performed by an independent auditor. This is true for all audits. Although you may want to conduct an audit of a provider yourself, the provider may view giving you access to a data center as a security issue, for example.

2.   A. Pass-through audits are a form of compliance inheritance. The audit does not speak to the completeness of the audit scope itself. Rather, it certifies that the controls implemented and managed by the provider are compliant. Your organization is required to meet compliance for your systems and data in the provider’s environment.

3.   C. The most accurate and therefore the best answer is that audits are used to prove or disprove compliance with corporate governance.

4.   B. Attestations are legal statements from a third party. They are used as a key tool when customers evaluate and work with cloud providers, because customers often are not allowed to perform their own assessments. Attestations differ from audits in that audits are generally performed to collect data and information, whereas an attestation checks the validity of this data and information to an agreed-upon procedure engagement (such as SOC). Attestations can be performed by certified public accountants (CPAs), but this answer doesn’t properly address the question.

5.   D. Audit management ensures that audit directives are implemented properly. All the other possible answers form part of this activity, but the best answer is that all of these directives are implemented properly.

6.   A. Although all the answers are not necessarily incorrect, CSA best practice recommends that particular attention be paid to the services and jurisdictions that are part of the audit scope, so this is the best answer.

7.   D. Providers should supply customers with evidence of compliance and artifacts when customers cannot generate these themselves. All the other answers are just plain wrong.

8.   D. An increased audit frequency lowers the chance of unknown deviation of the security posture in the provider’s environment. Continuous doesn’t mean real-time, and it does not imply any set schedule. It means that any changes or findings are discovered between certification cycles, usually through the use of automation.

9.   B. If a provider’s artifacts of compliance are insufficient, customers should collect their own. There’s no such thing as a scoping exclusion request.

10.   A. When selecting auditors, you always want to work with auditors that have knowledge of cloud computing. The CCSK certification validates an auditor’s understanding of cloud services.