The buck stops here.

—President Harry S. Truman

Although cloud computing didn’t exist when President Truman was in office, his statement is something to remember about your accountability when you outsource to the cloud. You can choose the third-party provider to which you will outsource the building and operational responsibilities of a cloud environment, but you can never outsource accountability. This is why proper governance is critical to your firm at the highest levels.

Although the title implies that there are two areas of focus in this domain, there are really four areas, or roles, that play a part in a strong governance and risk management program. The roles involved are governance, enterprise risk management, information risk management, and information security. The following provides a high-level understanding of these roles:

•   Governance Includes the policy, process, and internal controls that direct how an organization is run; it includes everything from structures and policies to leadership and other mechanisms for management. You can consider governance as assigning directive controls. The policies to be implemented will often be built from the corporate mission statement and will address the laws, regulations, and standards faced by a company that must be followed in order to continue operations. Governance relies on the compliance function to ensure that directives are being followed throughout the enterprise.

•   Enterprise risk management Includes managing overall risk for the organization, aligned with the organization’s governance and risk tolerance. Enterprise risk management (ERM) includes all areas of risk, not merely those concerned with technology.

•   Information risk management Addresses managing risk to information, including information technology (IT). Organizations face all sorts of risks, from financial to physical, and information is only one of multiple assets an organization needs to manage. If you work in IT, you are likely most acquainted with this area of risk management.

•   Information security Includes the tools and practices used to manage risk to information. Information security isn’t the be-all and end-all of managing information risks; policies, contracts, insurance, and other mechanisms also have roles to play (including physical security for nondigital information). However, a—if not the—primary role of information security is to provide the processes and controls required to protect electronic information and the systems we use to access it.

In a simplified hierarchy, information security is a tool of information risk management, which is a tool of enterprise risk management, which is a tool of governance. The four are all closely related but require individual focus, processes, and tools.

Governance

This section is divided into two main areas: first, a governance backgrounder that describes the role of corporate governance and governance changes that result from adopting cloud services and, second, the areas of importance to focus on regarding cloud governance issues.

Governance Backgrounder

Ever heard the expression, “it starts at the top”? Well, that’s enterprise governance in any company of any size. The governance function is centered at the board or the executive level in an organization. There are many aspects of governance, ranging from corporate governance to IT governance, but the important thing to remember is that all governance has a singular goal of enabling the organization to achieve its goals. This is why at a high level, governance can be directly connected all the way back to the corporate mission statement, and at an even higher level, governance can be connected back to the definition of what leadership considers the actual purpose of the company.

The components that make up corporate governance can vary widely. Figure 2-1 shows a high-level view of some of the more generally accepted components of corporate governance.

Figure 2-1   Corporate governance framework

For years, the “Anglo-American model” of governance has always stated that a company exists for the benefit of its shareholders, and its main goal in that pursuit is maximizing profits. In August 2019, the Business Roundtable, a group of nearly 200 chief executive officers from leading US companies, redefined the purposes of an American company: to invest in employees, deliver value to customers, deal ethically with suppliers, support local communities, embrace sustainable practices to protect the environment, and generate long-term value for shareholders. This statement is incredibly powerful, because it defines specific goals of a company, which will drive the governance function to meet these goals in addition to laws, regulations, standards, and other requirements the company faces.

Following corporate governance is IT governance. IT governance can be defined as the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals. Figure 2-2 shows a high-level view of the various components of IT governance. This is, of course, a very simple view of the IT governance function. For example, the latest version of the COBIT Core Model includes 40 governance and management objectives for establishing IT governance. You won’t be tested on these as part of the CCSK exam, but knowing the aspects of IT governance isn’t a bad thing.

Figure 2-2   Components of IT governance

This concludes the backgrounder section of governance. Now let’s look at how governance changes as a result of adopting cloud services.

Cloud Governance

Because cloud computing likely introduces a third party into the company mix, a company now has a form of indirect control based on contracts. Where a customer’s ability to define, enforce, and monitor adherence to company policies may be dictated by the cloud provider, corporate governance is impacted by the cloud. Additionally, key information related to service management of the cloud environment is (hopefully) produced by the cloud providers, not by the customers themselves. In fact, the only time that governance won’t be altered as a result of using the cloud is a scenario in which your own people have implemented automation and orchestration software in your own data center and your company fully manages it like any other system in your data center today. (Recall from Chapter 1 that a private cloud serves one organization only and doesn’t dictate the location or management.)

The primary issue to remember about governing cloud computing is that although an organization can outsource responsibility (authority over actions) for governance, a company can never outsource liability, even when using external providers. As such, the organization will always retain accountability (liability for actions, or lack of actions) if anything goes wrong. This is always true, with or without the cloud, but it is useful to keep in mind when you’re navigating cloud computing’s concepts of shared responsibility models.

With some cloud providers having more than a million customers, it is simply impossible for providers to give every customer everything they need from contract, service level agreement, and security control perspectives. As such, providers will supply customers with extremely standardized services (including contracts and service level agreements) that are consistent for all customers. Governance models cannot necessarily treat cloud providers the same way they’d treat dedicated external service providers, such as co-location or web hosting providers, which typically customize their offerings, including custom contracts, background screening of employees, and legal agreements, for each client.

The contract between the customer and the provider will identify the responsibilities and mechanisms for governance; the customer needs to understand both and identify any process gaps. If a gap is identified, the customer needs to adjust their own processes to close the gap or accept the associated risks.

Tools of Cloud Governance

Here’s some great news! Your company likely already has contracts in place with cloud providers, so you know what needs to be done when onboarding a third party. Unfortunately, though, the cloud provider contract is different from, say, a co-location provider contract, because with a co-location provider, you are outsourcing everything—the hardware, staff, management, operations, and so on. That said, you need to be aware of several tools and how they change with the cloud compared to other forms of outsourcing. These are covered in the next few sections.

Contracts The contract is the number one tool of governance. The legally binding contract agreement is your only “guarantee” of any level of service or commitment. Simply put, if it’s not in the contract, it doesn’t exist. Notice the quotes around the term “guarantee.” If the provider breaks the terms of the contract or doesn’t fulfill the terms of a service level agreement, you’re looking at a legal dispute. (Watch the guarantee scene from the movie Tommy Boy for further information on the value of some guarantees.)

The term “contract” is actually a little misleading, because it seems to imply that a single document is involved; however, the contract will often refer to other documents as well. Consider the following example from the first sentence of the Microsoft Azure Agreement:

This Microsoft Azure Agreement is between you or the entity you represent, or, if no such entity is designated by you in connection with a Subscription purchase or renewal, you individually (“you”) and Microsoft Corporation (“Microsoft”, “we”, “us”, or “our”) and consists of the below terms and conditions, as well as the Acceptable Use Policy, the Services Terms, the SLAs, and the Offer Details for your Subscription, or renewal (together, the “Agreement”).

So, basically, a contract includes the following legally binding documents:

•   Terms and Conditions This is the main document that describes aspects of the service, how customer data will be used, termination clauses, warranties, applicable laws, and other fascinating items written by the provider’s lawyers to protect them as much as the law will allow.

•   Acceptable Use Policy This states what you can and cannot do when consuming the service.

•   Services Terms This contains service-specific contractual agreements by the provider.

•   Service Level Agreements This details items such as availability uptime commitments and penalties for not meeting those commitments. Quite often, the penalties to the provider for failing to meet monthly service level agreements (such as 99.9 percent availability) take the form of extra service credits—and the customer usually needs to submit a claim and show evidence of unavailability.

•   Clauses Based on Your Subscription and/or Renewal These would be specific legal agreements based on your particular subscription. With cloud services, the commitments from a provider to the customer are largely based on the customer’s subscription level. Consider an extreme example: a free version of a product may have clauses that state that the provider can access your usage data, while the paid version doesn’t allow the provider to access your data. Make sure that you understand the subscription level and review that specific documentation.

Cloud Provider Assessments Assessment is part of the due diligence a customer must perform in advance of using a cloud provider. The assessment should leverage all available information, ranging from contract reviews to provider-supplied audit reports and reviews of technical documentation of the system. Technical assessments may be limited by the provider (for example, no physical access because of security concerns). How the provider supplies technical documentation is up to them: they may post detailed information online, or they may make it available only in-person at their offices for your review.

Aside from a technology perspective, most supplier assessments are performed as part of a cloud provider’s assessment. Assessed items generally include financial viability, history, feature offerings, third-party attestations, feedback from peers, and so on.

Compliance Reporting Two simple words summarize this governance tool—standards and scope. Leading cloud providers will spend vast sums of money to ensure that they can promote compliance with a wide multitude of standards. They go through the time and expense of obtaining these certifications and reports in order to attract clients that are subject to particular laws and regulations. All of the standards have one issue in common, however—the scope of the engagement. Take International Standards Organization/International Electrotechnical Commission (ISO/IEC) certification, for example. The scope of the ISO/IEC audit could be only the IT department. Where does that leave you if you’re looking for a cloud provider with the ISO/IEC certification that you want to use to make your provider selection decisions? It leads you to understand that merely being “certified” doesn’t mean anything if the service you are consuming is not within the scope of the audit.

Popular standards that providers often promote include the following:

•   NIST 800-53 This control set is part of the bigger NIST Risk Management Framework. If you work for a government agency, this is likely the control set that you are most familiar with. More than 600 controls in 800-53 cover low, moderate, and high classification systems.

•   FedRAMP The Federal Risk and Authorization Management Program tailors the NIST 800-53 control set for cloud services. Providers must be FedRAMP authorized (known as an Authority to Operate, or ATO) to offer their services to the US government.

•   ISO/IEC 27017 The “code of practice for information security controls based on ISO/IEC 27002 for cloud services” standard is essentially the control set from ISO 27002, tailored for cloud services.

•   COBIT The Control Objectives for Information and Related Technology (yeesh!) is a governance and risk management framework owned by ISACA. It is not a set of controls like Cloud Controls Matrix (CCM), FedRAMP, or ISO 27017. Rather, its focus is on enterprise governance and management of IT, not just security. You won’t likely see any provider promoting this as compliance, but it’s brought up in the guidance and it’s a mapping in the CCM.

•   PCI The good old Payment Card Industry and its Data Security Standard (DSS) is a very popular industry standard because of penalties associated with noncompliance. Just a note on this one: A provider being “PCI compliant” does not mean your applications are automagically “PCI compliant.” This is a perfect example of the shared responsibility of all cloud models, and you will need to assess your applications if they are part of the PCI cardholder data environment.

•   HIPAA The Health Insurance Portability and Accountability Act is US public law that requires data privacy and security provisions for safeguarding medical information. It is not cloud specific, but it does apply to the cloud if medical information is stored in a cloud environment.

Thankfully, the CSA Guidance doesn’t go into detail about all the standards out there, but there is one that you need to be aware of: System and Organization Controls (SOC, pronounced “sock”). The SOC (formerly known as Service Organization Control) by the American Institute of Certified Public Accountants (AICPA) is used by the vast majority of service providers to report on controls at a service organization. The SOC report is generated by an independent CPA and is available from the provider via a nondisclosure agreement (NDA). Although multiple report types are available (SOC 1, SOC 2, SOC 3), these reports are based on the AICPA Statements on Standards for Attestation Engagements 18 (SSAE 18) (previously SSAE 16) standard. Here’s a breakdown of the three SOC levels:

•   SOC 1 This SOC report is used for Internal Control over Financial Reporting (ICFR) and is used for entities that audit financial statements.

•   SOC 2 This SOC report is titled “Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy.” It deals with ensuring that controls at an organization are relevant for security, availability, and processing integrity of systems.

•   SOC 3 This publicly available high-level SOC report contains a statement from an independent CPA that a SOC engagement was performed, plus the high-level result of the assessment (for example, it could indicate that the vendor statement of security controls in place is accurate).

Now if that’s not quite confusing enough for you, the AICPA thought it would be a great idea to have different types of report levels as well:

•   Type 1 A point-in-time look at the design of the controls

•   Type 2 An inspection of the operating effectiveness of the controls

As you can see, you’ll probably want to receive and review the Type 2 report because it actually tests the controls in question. The bottom line here is that as a security professional, you want to get access to a provider’s SOC 2, Type 2, report. It will offer great detail into the security controls in place, tests performed, and test results.

Of course, providers aren’t forced to use a standard like SOC reporting or ISO to supply third-party assessment of controls. They could offer you a self-assessment they created that is based on a standard such as the CCM and CAIQ, covered in Chapter 1, or they may even allow potential clients to perform their own audits—but this is rare.

Risk Management

As mentioned earlier, enterprise risk management (ERM) is the overall management of risk for an organization, and information risk management (IRM) is focused on information and information systems. Both of these functions are related to the governance function, as governance ultimately determines acceptable risk to the organization as a whole. Recall from the previous governance section that the contract defines the roles and responsibilities for risk management between a cloud provider and a cloud customer. The contract, along with other documentation supplied by the provider, can be used to determine where potential for untreated risk exists. You also know that you can never outsource your overall responsibility and accountability for risk management to an external provider, so proper risk management is critically important for your organization. A review of the provider’s documentation, assessments, and audits will provide much more information to help with an effective risk decision.

Risk Management Backgrounder

Before discussing the changes to risk management as a result of the cloud, I think it’s important to discuss risk management basics for those who may not be familiar with this function. This backgrounder section cannot cover every aspect of risk management, as the topic is incredibly broad and frankly not applicable for your CCSK exam. If you are highly interested in the subject of risk management, I recommend you access the NIST 800-39 document that I used as the basis of this overview. If you are already very comfortable with the principles of risk management, feel free to jump to the next section.

ISACA defines risk management as “the process of identifying vulnerabilities and threats to the information resources used by an organization in achieving business objectives, and deciding what countermeasures, if any, to take in reducing risk to an acceptable level, based on the value of the information resource to the organization.” According to the “Managing Information Security Risk” publication by NIST (SP 800-39), risk management consists of four core activities. Following is a list of the activities, or steps, and a brief description of each.

Step 1: Risk Framing In this step, the company creates a risk management strategy that details how it assesses, responds to, and monitors risk. It takes into account the laws, regulations, and standards that shape the organization’s approach to managing risk. Most importantly for this discussion, it determines risk tolerance, which can be used to determine acceptable versus unacceptable risk. It is the basis upon which the company makes all risk decisions, from investments to operational decisions. This initial step demonstrates the need for strong collaboration between governance and risk management functions.

Step 2: Assessing Risk In this step, not surprisingly, risk assessment is used to identify, prioritize, and estimate risk to corporate assets (among other items). In this step, the company identifies potential threats and vulnerabilities and tries to determine the likelihood and impact of threats being realized by an exploited vulnerability. This assessment calculation is the very definition of risk. There are two main means of risk assessment: First, in qualitative risk assessment, a subjective ranking is applied (such as low, moderate, high) to the impact as well as the probability of a threat occurring, to drive a final risk ranking. Second, the quantitative risk assessment applies financial figures to assets. At the end of this exercise, the company can apply a value to each risk to determine whether it is acceptable or not based on the risk tolerance derived from the risk framing step (step 1).

Step 3: Responding to Risk In this step, a determination is made regarding the course of action required to respond to a perceived risk. Several response options are available: accept the risk and don’t apply any measures to reduce the impact of a threat being realized; avoid the risk by not proceeding with the operation; mitigate the risk by implementing controls to reduce the likelihood or impact of a threat being realized; share the risk by engaging in an activity with other parties or groups; and, finally, transfer the risk to another party by purchasing insurance (such as cyberinsurance), for example. In general, risk is mitigated by deploying a control to reduce the likelihood or impact of a risk being realized to an acceptable level. The risk that remains is called residual risk. In a cloud environment, there are, of course, two parties involved, and the provider may be the one that is deploying controls to mitigate risk. The residual risk will be considered either acceptable or unacceptable. If your company determines that it is an unacceptable risk, you need to deploy additional controls and further mitigate the risk, or avoid the risk by not using the service.

As for what is considered an acceptable risk and what is not, it all comes down to the customer company’s risk tolerance. Customers shouldn’t have a blanket clause as to what is considered acceptable risk for anything that occurs. Take a marketing “cats with hats” application versus an internal financial report application. Do both have the same security concerns? Of course they don’t. Your risk acceptance should align with the value and requirements of the assets involved. The goal over time for your company is to have an understanding of the cloud services that are consumed and the types of assets that can be used in each service.

Step 4: Monitoring Risk The final phase of risk management involves verifying the ongoing effectiveness of risk response measures and maintenance of compliance (audit and compliance subjects are covered in Chapter 4). Beyond this, though, identifying any changes made that may impact risk to an organization and ensuring that risk treatments remain appropriate are also important. Identification can be performed through manual processes such as threat assessments or automated processes such as configuration management, vulnerability assessments, and so on. In this step, process improvement activities can be identified and implemented.

Cloud Risk Management

Risk management is risk management, regardless of where your systems and information are stored. Risk still needs to be framed, assessed, responded to, and monitored. Risk management in a cloud environment must include the service models and deployment models, because these impact the shared responsibilities inherent to cloud services. The following sections address the changes that the cloud can effect on your current risk management.

The Effects of Service and Deployment Models

As the cloud is a shared responsibility model, we have to look at who is generally responsible for managing components from both service model and deployment model perspectives. We will start by looking at the impact of the service models, and then we’ll look at the impact of deployment models on governance and risk management.

Service Model Effects

As you may recall from Chapter 1, the service model will give you a high-level view of shared responsibilities. The more functionality the supplier provides, the more they will be responsible for all facets of information security.

Software as a Service SaaS is essentially renting access to a turnkey application that is supplied by the provider. Providers in the SaaS space range in size from very small to very large. Given the wide spectrum of vendors, it is critical that you ensure that a potential SaaS vendor is a proper fit for your company, because you are essentially outsourcing everything from the facilities up to the application itself, which places most responsibility for security on the provider.

Another consideration is that your SaaS provider may very well in turn be outsourcing to a Platform as a Service (PaaS) or an Infrastructure as a Service (IaaS) vendor. This establishes not just a third party, but fourth and possibly fifth parties as part of your outsourcing chain. If this is the case, you will need to determine which vendors are involved and assess those environments as well.

Platform as a Service The responsibility shift tilts more toward the customer with PaaS compared to SaaS. You have more capability to configure security within the product you are building on top of a shared platform that the provider fully manages. An example of this would be implementing encryption within an application built on a shared PaaS platform. In this scenario, information risk management and information security are focused primarily on the platform being procured and, of course, the application itself. Given that PaaS is breaking up the IT stack in novel ways, it is important that you review in detail how the contract provisions map to required controls and control opportunities.

Infrastructure as a Service You already know that of all the three service models, IaaS is the closest to a traditional data center. As such, this service model results in the customer having the most responsibility to configure controls, be they supplied by the provider (such as logging) or implemented by the customer (such as host-based firewalls in an instance). The issue with governance and risk management lies in the orchestration and management layers supplied by the provider. As most IaaS is built on virtualization technology, the provider’s selection and configuration of the hypervisor and its subsequent ability to isolate workloads properly is completely out of your control. The only thing you can do about addressing potential isolation failure is to understand how the provider mitigates against this possibility and make an informed decision in advance of using that provider. As you will likely have no access to audit these controls yourself, this becomes a document review exercise, assuming the provider is transparent with their processes.

Deployment Model Effects

The deployment model is based on ownership and management of the infrastructure as well as the trust level of other tenants. So it makes sense that changes in governance and risk management will result. Let’s look at the various deployment models in public, private (both hosted and on-premises), community, and hybrid clouds to determine how they change governance and risk management.

Public Cloud This model is very straightforward. A third party owns and manages the infrastructure, and the facilities are located outside of your data center. Employees of the provider and possibly unknown subcontractors they engage manage everything. Fellow tenants are untrusted, as anyone with a credit card and a dream can run workloads alongside your workloads, possibly on the same hardware.

Negotiated contracts that address controls and other technical issues are unlikely in a public cloud because of the volume of customers and the natural multitenancy of public cloud offerings. As such, you will have to assess the controls implemented by the provider, perform a gap assessment, and fill in the gaps yourself. Or you will have to accept the risk (which again should always be done on a per-asset basis given its particular value).

Private Cloud Governance in a private cloud boils down to one very simple question: which party owns and manages the private cloud? You could call a provider and have them spin up and manage a private cloud for you, or you could have your people install the private cloud automation and orchestration software to turn your data center into a “private cloud.” In the event that your company owns and operates the private cloud, nothing changes. If, on the other hand, you have outsourced the build and management of your private cloud, you have a hosted private cloud, and you have to treat the relationship as you would any other third-party relationship. It will, however, be different from governance of a public cloud, because you are dealing with a one-to-one type of relationship. Just as you would with any other supplier contract, you have to make sure your provider is contractually obligated to do everything you want in advance. If you request something and the provider is not obligated to supply that service, you will likely face the dreaded “change order” charges as you would with any other supplier today.

Hybrid and Community Cloud With the hybrid and community cloud deployment models, you have two areas of focus for governance activities: internal and the cloud. With hybrid clouds, the governance strategy must consider the minimum common set of controls that make up the cloud service provider’s contract and the organization’s internal governance agreements. In both hybrid and community models, the cloud user is either connecting two cloud environments or a cloud environment and a data center.

For community clouds specifically, governance extends to the relationships with those organizations that are part of the community that shares the cloud, not just the provider and the customer. This includes community membership relations and financial relationships, as well as how to respond when a member leaves the community.

Cloud Risk Management Trade-Offs

There are advantages and disadvantages to managing enterprise risk for the cloud deployment models presented in this chapter. These factors are, as you would expect, more pronounced for a public cloud and a hosted private cloud:

•   You have less physical control over assets and their controls and processes. You don’t physically control the infrastructure or the provider’s internal processes.

•   You have a greater reliance on contracts, audits, and assessments, as you lack day-to-day visibility or management.

•   You lack direct control. This creates an increased requirement for proactive management of the relationship and adherence to contracts, which extends beyond the initial contract signing and audits. Cloud providers also constantly evolve their products and services to remain competitive, and these ongoing innovations may exceed, strain, or not be covered by existing agreements and assessments.

•   Cloud customers have a reduced need (and an associated reduction in costs) to manage risks that the cloud provider addresses under the shared responsibility model. You haven’t outsourced accountability for managing the risk, but you can certainly outsource the management of some risks.

Assessing Cloud Service Providers

You are dealing with two types of risk management when you assess the cloud: the risk associated with use of third-party cloud service providers and the risk associated with the implementation of your systems in the cloud. The fundamental aspects of risk management (covered earlier in the chapter) don’t change as a result of the cloud. The framework, processes, and tools for all aspects of governance, risk, and compliance (GRC) that you use today can and should be applied to a cloud environment. The biggest change to your GRC program as a result of adopting cloud services will rest in your initial and continued assessment of service providers.

Supplier Assessments

The initial supplier assessment sets the groundwork for the cloud risk management program. The following steps and a graphical view of these steps (Figure 2-3) show what you should follow as part of a supplier assessment:

Figure 2-3   Supplier assessment steps. (Used with permission of Cloud Security Alliance.)

1.   Request or acquire documentation.

2.   Review the provider’s security program and documentation.

3.   Review any legal, regulatory, contractual, and jurisdictional requirements for both the provider and your organization.

4.   Evaluate the contracted service in the context of your information assets.

5.   Separately evaluate the overall provider, such as its finances/stability, reputation, and outsourcers.

Because you know that governance and risk management of a cloud provider is never a one-and-done approach, you need to stay on top of the relationship. To that end, consider the following recommendations for vendor risk management:

•   Don’t assume all services from a particular provider meet the same audit/assessment standards. You will have to assess the latest audit/assessment reports and determine whether a service you are considering was in scope and tested or not.

•   Periodic assessments should be scheduled and automated if possible.

Chapter Review

This chapter reviewed the recommendations by the Cloud Security Alliance surrounding the elements of governance and risk management changes that are associated with cloud consumption. The CCSK exam will not test you on the various standards out there that can be leveraged for traditional IT consumption. Your goal is to understand the differences that occur with governance and risk management as a result of consuming cloud services. To that end, make sure you fully understand the following points, which were all covered in this chapter:

•   Identify the shared responsibilities of security and risk management based on the chosen cloud deployment and service models. Develop a cloud governance framework/model as per relevant industry best practices, global standards, and regulations such as CSA CCM, COBIT, NIST RMF, ISO/IEC 27017, HIPAA, PCI DSS, EU GDPR, and so on.

•   Understand how a contract affects your governance framework/model. You’re introducing a supply chain when consuming cloud services.

•   Don’t assume that you can effectively negotiate contracts with a cloud provider—but this also shouldn’t necessarily stop you from using that provider. If a contract can’t be effectively negotiated and you perceive an unacceptable risk that the provider accepts, consider implementation of alternative mechanisms to manage (mitigate) that risk (such as monitoring or encryption).

•   Align risk requirements to the specific assets involved and the risk tolerance for those assets. There is no such thing as a single security solution that covers everything. Asset values and classification are very different and need to be addressed separately.

•   Create a specific risk management and risk acceptance/mitigation methodology to assess the risks of every solution in the space. The Cloud Controls Matrix (covered in Chapter 1) can be an excellent starting point to create this process, but the process will need to be tailored based on your company’s specific risk tolerance for specific assets.

•   Use controls to manage residual risks. If you cannot deploy controls to manage risk that the provider accepts, you have two choices: accept or avoid the risks.

•   Use tooling to track approved providers based on asset type (for example, linked to data classification), cloud usage, and management. This tooling can be anything from a spreadsheet to an advanced supplier tracking tool.

•   Like Ferris Bueller said, life moves pretty fast. If you don’t stop and look around once in a while, you could miss it. Cloud provider reassessments should occur on a scheduled basis and be automated to the extent possible.

•   Develop a process for cloud provider assessments. This should include the following:

•   Contract review

•   Self-reported compliance review

•   Documentation and policies

•   Available audits and assessments

•   Service reviews adapting to the customer’s requirements

•   Strong change-management policies to monitor changes in the organization’s use of the cloud services

Questions

1.   Chris is looking to procure a new CRM SaaS solution for his organization’s business unit. What is the first step Chris should take as part of performing a risk assessment of a potential vendor?

A.   Determine monthly costs.

B.   Ask reference clients about their satisfaction with the product.

C.   Determine the level of sensitivity of data that will be stored in the application.

D.   Obtain and review supplier documentation.

2.   Pat is looking for an industry standard set of controls that are cloud specific. What can Pat select controls from to create a baseline risk assessment process?

A.   ISO 27001

B.   NIST RMF

C.   COBIT

D.   CCM

3.   Your IaaS vendor assures you that your applications will be PCI compliant if you use their cloud offering. What is wrong with this statement?

A.   The vendor has no idea what they are talking about.

B.   The vendor is lying to you.

C.   The vendor doesn’t understand the shared responsibility model of cloud.

D.   All of the above are true.

4.   How often should risk assessments be performed against a cloud service provider?

A.   Upon initial assessment prior to on-boarding

B.   Upon initial assessment and on an ongoing basis

C.   Providers don’t allow customers to perform risk assessments

D.   There are no risks associated with cloud services

5.   Which service model is most congruent with existing governance and risk management processes?

A.   SaaS

B.   PaaS

C.   IaaS

D.   Internally managed private cloud

6.   When you’re assessing a provider, which of the following SOC reports should be sought from a vendor when assessing security controls?

A.   SOC 1, Type 1

B.   SOC 1, Type 2

C.   SOC 2, Type 1

D.   SOC 3

7.   What is a natural property of multitenancy?

A.   Inflexible contracts

B.   Being hacked by co-tenants

C.   Economies of scale

D.   Shared responsibility

8.   What risk must be mitigated by a customer?

A.   Any risk

B.   Risks associated with the service model

C.   Risks accepted by the provider

D.   Risks listed in the Cloud Controls Matrix

9.   What is the number one tool of governance in a cloud?

A.   Reviewing vendor certifications

B.   Training your people on cloud security

C.   Working with auditors with cloud experience

D.   Contract reviews

10.   What must be first understood when considering governance of a private cloud?

A.   Who owns and manages the private cloud

B.   The automation and orchestration software used

C.   The credentials of the people managing the private cloud

D.   Contract clauses in place with the private cloud vendor

Answers

1.   D. The first step in performing a risk assessment is requesting documentation.

2.   D. The CCM has a series of controls that are cloud specific. None of the other answers are applicable.

3.   D. All of the statements are applicable.

4.   B. Risk assessments should be performed prior to and throughout the use of a provider’s offering.

5.   C. IaaS is the service model most congruent with traditional governance and risk management. The private cloud is a deployment model, not a service model. Note: Watch out for trick answers like this on any technical exam!

6.   C. The best answer listed is SOC 2, Type 1. SOC 1 deals with financial reporting controls. A SOC 3 report doesn’t contain any tests performed or their results. A SOC 2, Type 2, report is the best to use when reviewing a provider from a security perspective, but since it’s not listed as a potential answer, SOC 2, Type 1, is the best possible answer.

7.   A. Inflexible contracts are a natural characteristic of multitenancy because the provider cannot afford or manage a million-plus custom contracts.

8.   C. The best answer is that a customer must mitigate any risk accepted by the provider, except for any risk the customer determines unacceptable. This must be based on the value of a particular system and cannot be a blanket approach.

9.   D. Contract reviews are the primary tool associated with governance in a cloud.

10.   A. The first item that must be understood when you’re dealing with a private cloud is who owns and manages the cloud infrastructure. If the infrastructure is internally owned and managed, little changes. If it’s outsourced, governance changes to reflect the fact that the supplier is in control.