The beginning is the most important part of the work.

—Plato

As Plato said, the most important part of the work is at the beginning, which should start with laying a strong foundation. This chapter serves as the foundation for the chapters that follow and includes concepts that you need to understand to be a successful CSA Certificate of Cloud Security Knowledge (CCSK) candidate. It describes and defines cloud computing, establishes baseline terminology, and details the overall logical and architectural frameworks such as the International Standards Organization/International Electrotechnical Commission (ISO/IEC) 17789 standard and the National Institute of Standards and Technology (NIST) 800-145 and 500-292 standards, which are discussed throughout the book.

Although cloud services are presented to the consumer in a user-friendly format, the implementation required to support upwards of 1 million customers behind the scenes is quite different from what even the most seasoned IT professionals are accustomed to. The cloud service provider (CSP) creates and manages an offering that consists of pools of resources (Compute, Network, Storage) that are accessed via controllers that communicate using application programming interfaces (APIs). It is through these pools and API access that several essential characteristics of the cloud (such as self-service, elasticity, and resource pooling) are possible. A very high-level diagram shown in Figure 1-1 demonstrates how the controller is key to serving resources in an abstracted (you don’t access the hardware directly) and orchestrated (coordinates the processes) manner. In a nutshell, you basically request something (Compute, Network, Storage) from the controller, and the controller takes care of the rest for you.

Figure 1-1   Cloud controllers and pools of resources. (Used with permission of Cloud Security Alliance.)

When most people think of the cloud, they think of how “cheap” it is in comparison to the traditional information technology (IT) structure. While cloud computing can be (but is not always) cheaper because of economies of scale at the provider’s side, cloud consumers must appreciate that the provider cannot be everything to everyone (that is, the CSP cannot meet everyone’s security policies). As a result, you need to be very aware of the shared responsibilities that come with any potential cost savings. The provider will supply you with some security controls, but you will be responsible for implementing other controls. The bottom line here is this: the idea that a CSP takes care of everything for you is a fallacy that really needs to die. Although the shared responsibilities are primarily based on the service model consumed (Software as a Service [SaaS], Platform as a Service [PaaS], or Infrastructure as a Service [IaaS]), the deployment model also comes into play when determining what a consumer must do to secure a cloud environment properly.

Cloud computing offers tremendous potential benefits in agility, resiliency, and economy. As a result, organizations can move faster (no hardware purchases and racking/stacking servers), reduce downtime (if architected to take advantage of elasticity and other cloud characteristics), and save money (no capital expenses, and operational expenditures can be reduced by right-sizing server specs and quantity on the fly to meet actual demand). As for security at the provider level, the CSP business model requires that extremely strong controls be in place if the provider is to remain in business. (Would you do business with a cloud provider that was successfully hacked three times in the past year?) I’m not saying that providers must create some sort of impenetrable security through breakthrough research on the security capabilities of dilithium crystals—but they can, and generally will, spend appropriate time and money to make certain that security is very well architected into everything they do. In fact, I’m kind of jealous of the security function in provider environments. I mean, there aren’t too many companies out there that will spend months making sure that security is fully addressed before going live with a product. In most organizations, the security group is given the heads-up on Wednesday that a new application is being deployed on Saturday and that it’s a top priority, so security will have to be addressed in the next version.

The cloud is really what you make of it. You can simply migrate a server in a “like-for-like” fashion by performing a physical-to-virtual (P2V) migration to create that very same system running in a cloud environment. You might think this would be the easiest way to adopt cloud services, but the thing is, all you’ve really done is take a server that you have physical control over and make a virtual image of it, so that now you are running a single point of failure in someone else’s physical environment over which you have no control.

The real power of the cloud is manifested when you understand and adopt cloud-native models and adjust your architectures and controls to align with the features and capabilities of cloud platforms. If architected properly, servers can be treated as cattle, not pets. (This expression is often used to describe a pattern where servers are viewed as easily replaceable commodities, not “long-standing” resources, as they are in a traditional environment.) The focus of workload management moves from “we need X servers” to “we need this application to serve X concurrent connections.” In fact, you may not even have servers to manage if you are leveraging serverless computing (aka functions). Although I haven’t covered serverless computing yet (that happens in Chapter 7), I’m using this opportunity to emphasize that security in a cloud environment can drastically change based on how you use it, up to and including having to secure something that never existed in the past.

What follows in this chapter builds a foundation for the rest of the book, provides a common language and understanding of cloud computing for security professionals, begins highlighting the differences between cloud and traditional computing, and helps guide security professionals toward adopting cloud-native approaches that result in better security (and other benefits), instead of creating more risks.

Cloud Logical Model

The cloud logical model is a CSA creation that clearly defines four layers of functionality and applicable security requirements that exist in both traditional and cloud environments:

•   Infrastructure layer Infrastructure security

•   Metastructure layer Virtual environment security

•   Infostructure layer Data security

•   Applistructure layer Application and operating system security

The following sections describe the layers of the logical model as covered by the CSA.

Infrastructure

The servers, networking, and storage pools exist at this layer. Security at this layer involves properly securing the physical world. Do you run a private cloud that you own? You own this layer. Have a public cloud? This layer is owned and operated by someone else. In other words, it’s the provider’s world, and you’re just working in it.

Metastructure

This layer is the game-changing aspect of cloud. In this layer, you both configure and manage a cloud deployment of any type. The single biggest thing you need to understand immediately about the difference between the cloud and traditional IT is the metastructure in your data center. It is within the metastructure logical layer that you build the virtual tools required for a virtual world (the cloud).

You’ll perform configuration in the management plane through a graphical user interface (GUI), a command-line interface (CLI), or an API, depending on what the provider offers to interact with its infrastructure. Right about now, I like to call out the need for virtual tools for a virtual world. Want to add a new user for SaaS? You do it here. Want to set up a zero-trust network in IaaS? This is the place to do it.

If your team knows nothing about the metastructure, they know nothing about securely configuring, managing, or responding to incidents in the cloud. Make no mistake: you are in charge of configuring and managing this layer. Configuration and management mistakes in this layer are why so many companies have been burned in the past when using cloud services (and will likely continue to be burned for the rest of time).

Infostructure

This is where the information and data reside. This could be file storage, databases—whatever. Security in this layer doesn’t really change; how you secure things may change, but the principles of data security remain the same.

Applistructure

Applications and all of the services used to build and support them reside here. Your applications could be running on a Microsoft or Linux server of your own, or they could be running in a wide variety of new technologies such as containers, microservices, or serverless networks (I cover these technologies later). If you take an image of a running system and migrate it into the cloud, nothing changes from a security perspective. In this scenario, operating systems will always need patches, and application security still applies as it always has. As you start to build “cloud-native” applications to take advantage of the new technologies the cloud offers, your security is likely to change dramatically. I’ll cover these changes in Chapter 10.

Cloud Computing Definitions

You’ll find many definitions for “the cloud” out in the marketplace. For the CCSK exam, you really need to care about only two organizations and how they describe what a cloud comprises. Both NIST and CSA state that there are five essential characteristics, three service models, and four deployment models. You will need to memorize these for the CCSK exam. Figure 1-2 gives a graphical view of these items.

Figure 1-2   A cloud comprises five essential characteristics, three service models, and four deployment models. (Used with permission of Cloud Security Alliance.)

Essential Characteristics

Simply stated, the following essential characteristics determine whether an offering is really a cloud service or not. If an organization is trying to sell you its “cloud service” and it doesn’t have the five characteristics discussed here, you’re getting “cloudwashed” (a term for trying to sell a non-cloud service as a cloud service) and not really getting the value that the cloud can bring to your company.

Resource Pooling

Resources (Compute, Network, Storage) are the most fundamental characteristic of the cloud. Resources are pooled, and consumers are granted access. A consumer’s access to the pools is tightly isolated from that of other consumers, typically based on policies at the provider’s side. NIST 800-145 specifically calls out multitenancy as an aspect of this essential characteristic.

Broad Network Access

In this characteristic, the service is available over a network (such as the Internet). There is no special requirement for direct physical connectivity or provider-supplied network connectivity. For example, you could manage an entire IaaS implementation via the browser on your cell phone. (I highly recommend not doing this, but you could if you really want to ruin your eyesight!)

Rapid Elasticity

This characteristic is the most powerful aspect of cloud. It enables consumers to scale resources based on demand, often automatically (note that access can be manual and scaling still applies). Scaling can occur in a couple of different ways. Scaling up generally refers to using more powerful servers (such as a four-CPU configuration as opposed to two), whereas scaling out refers to adding more servers (for example, adding servers to a web farm to service requests). Depending on the application and architecture, you want to make sure your provider supports scaling either up or out to meet demand. In addition to having the ability to add capacity when demand increases, you need to be able to scale down when demand drops. This aspect is critical, because you don’t want to scale up to respond to a temporary increase in demand—you’d stay there in perpetuity and be surprised when the provider’s bill is suddenly three times what it was the month before!

Measured Service

The measured service essential characteristic makes the cloud a pay-as-you-go model of computing: you’re simply charged for what you use. Another term used in the CSA Guidance is “utility computing,” which is akin to how you consume electricity or water from a utility.

On-Demand Self-Service

You have the ability to provision resources on your own without human intervention at the provider’s side. Put another way, if your provider tells you that your ticket for a new server instance is very important to them and they will act on it in 48 to 72 hours, you’re being cloudwashed. In Chapter 10, you’ll see how this self-service characteristic can be used to automate security response capability using APIs through the implementation of event-driven security.

Cloud Service Models

The service model is a portion of the cloud reference architectures from ISO/IEC 17789 and NIST 500-292 documentation (CSA research uses the NIST model). The service model is presented as a stack to gain a high-level understanding of what is performed by a cloud service provider. This stack may be referred to as the “SPI” (SaaS, PaaS, IaaS) stack or SPI tiers. Figure 1-3 depicts the service models and how they are built on top of each other to form the SPI stack.

Figure 1-3   Service models are arranged on an SPI stack. (Used with permission of Cloud Security Alliance.)

Unfortunately, the marketing folks took notice of the “as a service” part and went pretty wild with it. As a result, there are all kinds of “as a service” categories such as Identity as a Service (IDaaS), Function as a Service (FaaS), and anything else that sounds “cool.” The reality, as far as your exam is concerned, is that three service models form the SPI stack (or tiers).

A final note about the SPI stack: Not every available category of service fits in nicely and cleanly into one of the three tiers. (Some may even span tiers!) Remember that this is merely a descriptive tool that gives you an idea of what the provider is offering regarding the responsibility shift associated with the offering. It is by no means a rigid framework.

Infrastructure as a Service

IaaS is the underlying foundation that consists of the physical facilities and infrastructure hardware. The hardware itself may be customized, proprietary, or standard off the shelf, but it’s still hardware, like you’ll find in any data center. The difference, however, is in the resource pooling, abstraction, automation, and orchestration. Abstraction is usually based on virtualization of servers, networks, and/or storage. It is this abstraction that allows for the pools of resources to be created (for example, a group of hypervisors all working together). The orchestration enables a controller to request resources from the pools of resources, and all this is automated through the use of APIs (mostly RESTful APIs).

Let’s look at a scenario that ties this all together. Say you want to create an Ubuntu Server instance with two CPUs, 12GB of RAM, 2TB of storage, and two network cards. Here’s what happens behind the scenes at the provider side (shown in Figure 1-4):

Figure 1-4   Automation and orchestration of cloud components

1.   The cloud controller contacts the compute controller to request that a new server with two CPUs and 12GB of RAM be created.

2.   The cloud controller contacts the storage controller to allocate 2TB of storage. This storage is connected to the new server instance through a storage network.

3.   The cloud controller requests two virtual network interface cards from the network controller.

After all of this is performed, the cloud controller takes the requested Ubuntu Server image, copies it to the newly created virtual server, boots it, and configures it. Once this is done (measured in seconds or minutes), the controller makes the connection information available to the consumer.

The IaaS service can usually be accessed via multiple methods—web, CLI, or API. These interfaces are created and made available by the provider for customers to manage their virtual environment, hence the term cloud management plane (and is part of the metastructure logical model covered earlier in this chapter). In fact, the display of a web interface is mainly for human convenience. The provider will take actions performed graphically and convert them to API calls that are then executed. As a cloud consumer, anything you can do via the web interface can be done via the API calls that are exposed. More mature cloud implementations by consumers are programmatically driven through accessing APIs. In fact, this programmatic-driven virtual infrastructure (referred to as a software defined infrastructure, which is covered in Chapter 6) is something that every cloud consumer should strive for. The less human intervention through a web browser, the better, because there will be less human error and a much higher level of agility.

Platform as a Service

Of the three service models, PaaS is the blurriest of all of them. By CSA definition, PaaS adds a layer of integration with application development frameworks; middleware capabilities; and functions such as databases, messaging, and queuing. Figure 1-5 demonstrates a PaaS offering built on top of IaaS that creates a shared platform on which applications are run.

Figure 1-5   PaaS offering built on top of IaaS. (Used with permission of Cloud Security Alliance.)

In the PaaS service model, the provider builds the infrastructure (or leverages IaaS from another provider), creates a shared platform that customers will leverage, and may expose security controls they believe customers want control over. The main benefit of using PaaS is that it removes the overhead associated with building and maintaining servers and shifts that responsibility over to the provider (the service becomes somewhat of a black box). Customers in turn leverage this multitenant platform that is fully managed by the provider.

You can think of PaaS as a development platform that you can use to gain quick access to an environment to build things on, or to leverage for functionality. Take a “Database as a Service” PaaS offering, for example. Rather than launching an instance, configuring the operating system, and then installing and configuring your chosen SQL software, you simply choose the SQL platform you want and answer a few questions, and your database is available within minutes.

The downside to PaaS, as far as security is concerned, is that controls exposed to the customer are restricted compared to those possible in IaaS. Consider this example scenario: A major provider’s SQL PaaS offering enforces an eight-character password for the master SQL account. It’s embedded within the service and isn’t even part of the provider’s integrated access management (IAM) offering. There’s no password complexity enforcement, no rotation, and no way to check to see whether the password meets policy. This isn’t to say PaaS is inherently insecure; it may, in fact, be more secure than a compliant application built in IaaS or in your own data center. But compliance isn’t security, and vice versa.

Change management is another issue you can run into with the PaaS provider owning and managing the platform. The provider can, and will, change what platforms will be supported and which ones will be deprecated over time. It is on you not only to be advised of these changes but also to identify potential issues and fix them before your provider makes the change. For example, if you are running application code in a development platform, you may eventually get an e-mail from your vendor announcing the introduction of a change to the platform that will break your application if your code has a dependency on functionality that is being deprecated. In a way, your provider is now dictating part of your change management. The provider may give you weeks, or they may give you months. It’s up to them, not you, because they own the platform.

Software as a Service

The SaaS model can be simply defined as “renting a turnkey application from a provider.” All SaaS applications are considered multitenant in nature and support access by web browsers and mobile applications. In many cases, SaaS applications also support access via API calls. The type of API supported (REST versus SOAP) and capabilities offered via the API are dependent on the provider in question.

The architecture of an SaaS application behind the scenes can range from a single server running both web and SQL services (read: single point of failure), or it can be an extremely complex system that consists of load balancers, redundant server farms, serverless components, and anything else imaginable. There are no rules or regulations as to what an SaaS (or any service model) provider must or must not do.

From a security and due diligence perspective, an important aspect of SaaS services is that the SaaS provider may use a separate provider for IaaS or PaaS purposes. The biggest issue here has to do with salespeople exaggerating the security of their application because it’s being run in a different provider network. To be honest, I can’t say if this happens because of ignorance or because they have no problem lying to prospective clients. As you already know, the cloud is a shared responsibility, and the SaaS vendor is just another client to the IaaS provider. If the application you are consuming has security issues at the applistructure layer (such as privilege escalation), that is 100 percent on the SaaS vendor. Along the same lines, the SaaS vendor who says their application is PCI- or HIPAA-compliant because it’s being run in a compliant infrastructure is equally guilty of ignorance or worse. I’ll cover the concept of compliance inheritance in greater detail in Chapter 4.

Cloud Deployment Models

Both NIST and ISO/IEC call out four deployment models, which refer to how the technologies are owned and how they are consumed. Deployment models are separate from the service models; with deployment models, you can have a private PaaS, for example. The main item to remember for your CCSK exam is the level of trust of other tenants who also use the service.

Public Cloud

This one is pretty simple. Anyone in the world with a credit card (stolen or not) can sign up to use the service. The infrastructure is owned and managed by a third party and is located off premises—somewhere other than your location.

Private Cloud

A private cloud is built for a single organization. Period. Full stop. Notice that unlike what I did with the public cloud, I’m not saying who owns or manages the infrastructure, and I didn’t state whether it was on or off premises. That’s because it can be any combination. You can have your own team install and manage a cloud infrastructure in your data center, or you can call a private cloud supplier and they could spin one up for you in their data center. The important fact is that only trusted people (well, people within your organization at least) will be accessing the cloud. Another trick in understanding what constitutes a private cloud is that it is really nothing more than controller software that automates and orchestrates access to pools of resources.

Community Cloud

A community cloud is generally built for multiple trusted organizations with similar concerns (such as a risk profile). The community cloud is much like a private cloud in that it can be built and managed by your company, or it can be outsourced. The co-tenants are also contractually bound. The key difference between a private and a community cloud is that the financial risk is shared across multiple contractually trusted organizations in the community cloud.

Hybrid Cloud

A hybrid cloud is an interesting model with regard to how its definition has changed over the years. A hybrid cloud has historically been referred to as the connection of two different clouds (such as a public and private cloud) that are bound together by standardized or proprietary technologies that enabled data and application portability. In the past few years, however, this term has been extended to include a non-cloud data center being connected, or bridged, to a cloud provider.

The most important capabilities that are associated with the hybrid deployment model are portability and cloud bursting. Portability is the ability to shift where a workload is executed—for example, creating a P2V image of a physical server and moving that to a cloud environment. The connectivity between your data center and the cloud environment (hybrid) makes this possible. Cloud bursting means leveraging a cloud provider to supply additional resources to meet additional load. In this scenario, you could have a load balancer that will direct incoming web traffic either to internal or to cloud-based systems depending on current load.

Cloud Security Scope and the Shared Responsibility Model

When looking at securing or assessing a cloud environment, you should keep in mind that the CSP is always responsible for implementing and configuring some aspects of the computing environment, and you are responsible for other aspects of the environment. This split is referred to as the shared responsibility model of the cloud. This shared responsibility model will determine the scope of each party’s cloud security efforts.

Shared Responsibility Model

You know that the cloud has a security responsibility shift. You also know that this responsibility shift is based on the metastructure, because it includes the management plane. All traditional security principles and domains remain the same. The differentiator with the cloud is that the nature of risks, roles and responsibilities, and implementation of controls changes, often dramatically.

When thinking of the responsibility shifts, you should try to remember that the provider is going to supply customers with security that will satisfy most requirements, but you can’t expect miracles. The provider will never know that you recently fired an employee and that the employee’s access should be revoked. That’s on you!

From a risk-tolerance perspective, every company, even the function in every company, will be different, and it’s impossible for the provider to address every risk that every customer may need addressed, even for items the provider is responsible for. For all the models, you have general risk approaches: accept the risk, mitigate the risk by deploying a control to minimize the impact or likelihood, or avoid the risk.

For your exam, you should know that security responsibility maps to the degree of control any given actor has over the architecture stack. This is dictated primarily by the service model being consumed.

Table 1-1 shows a high-level breakdown of the security responsibility shift that comes with each service model in the SPI stack and how it compares to a traditional (on-premises) data center.

Table 1-1   Security Responsibility for Different Service Models

Notice in the table that in all the models, the customer is never outsourcing everything to the provider. You will always maintain a degree of responsibility, no matter what service model is used.

Let’s take a look at a few examples of each service model to help you better understand Table 1-1:

•   SaaS You’re renting access to a turnkey application. The provider is responsible for the application itself and everything that supports it, down to the physical security. As the customer, you’re limited to what is exposed to you as a configurable item. For example, the provider could enable you to create a new user and assign certain permissions to that account, or it may allow for only one type of user; it’s up to them to create it, and it’s up to you to determine whether it’s acceptable based on your risk tolerance.

•   PaaS In this example, we see a shared responsibility for the application security as well as the network security entries. Consider a scenario where you’re using PaaS to run a custom application that you created. All the security surrounding the application code is on you—it’s your application after all! But why is it shared? It’s shared because the provider is responsible for the platform you’re using to run the application on. As for the network security portion, the provider maintains the network and supplies standard security controls (such as firewalls and intrusion prevention systems), but what if you want certain IP addresses blocked? That part would be on you to integrate into your code, or you could use a web application firewall, for example.

•   IaaS This one is pretty simple, right? You’re involved in everything aside from the facilities, physical hardware, and hypervisor. For instance, the provider may offer you operating system images that have all the latest patches installed, but once you launch an image to make your own instance, you’re responsible for patching and securing everything to meet your security policies. As far as the network security entry, this is where things get interesting. You are responsible for using the network controls the provider makes available (such as a virtual firewall service like a security group). The provider creates the virtual firewall service and exposes that security control to customers so they can configure it according to their requirements. It’s not the provider’s responsibility to configure those for you.

Figure 1-6 shows how the security responsibility shifts based on the service model.

Figure 1-6   Security responsibility shifts based on service model. (Used with permission of Cloud Security Alliance.)

The most important security consideration is knowing who is responsible for particular controls in any given cloud workload. In other words, you can’t just assume a provider uses a particular control because they are providing a particular service model (SaaS, PaaS, IaaS). As already mentioned, the service models provide a description; it’s not a firm framework. To get to the bottom of who is responsible for doing what, you should ask the following questions for every project:

•   What does the provider do?

•   What does the consumer need to do?

•   Does the cloud provider enable customers to do what they need to do?

•   What is included in the documentation the provider gives to customers?

•   What is guaranteed in the contract and service level agreements?

Cloud Security Alliance Tools

OK, so you know there’s a shared responsibility, you know that at a high level, customers are responsible for determining what controls need to be in place according to compliance standards, and you know that providers should implement security and be transparent about this—but wouldn’t it be awesome if you had some kind of control model or framework to follow when investigating a provider security capability? Good news! The CSA has tools that you can use to assess security controls in a cloud environment in the Cloud Controls Matrix (CCM) and the Consensus Assessments Initiative Questionnaire (CAIQ). CSA even offers a freely available repository of provider-completed CAIQ responses, called the Security Trust Assurance and Risk (STAR) registry. We’ll cover these tools at an appropriate level for the CCSK exam.

Cloud Controls Matrix

The CCM tool contains more than 130 cloud security controls across 16 domains and maps them to multiple security and compliance standards. CCM version 3.0.1 is tested as part of the CCSK v4 exam. The nice thing about the CCM is that it can be used to document the security responsibilities of both the provider security controls and your own implementation of systems in a cloud environment.

If you haven’t done so already, take a moment to access the CCM by downloading it from the CSA web site (cloudsecurityalliance.org). You should probably download the CAIQ at the same time, because I’m covering that one next. Because I can’t go through every single entry (nor do you want to!), I’m going to use the first control in the CCM as a guide to understanding the structure of the spreadsheet.

The structure of the CCM itself is broken down into the following portions:

•   Control Domain and Control This section lists the control domain and an individual control. For example, the first entry in the CCM is the “Application and Interface Security” domain, and “Application Security” is the individual control.

•   Control ID This is a simple identification code for the control in question. Using the first entry as a reference, this is called AIS-01.

•   Updated Control Specification This statement specifies the control objective. The wording for AIS-01 states, “Applications and programming interfaces (APIs) shall be designed, developed, deployed, and tested in accordance with leading industry standards (e.g., OWASP for web applications) and adhere to applicable legal, statutory, or regulatory compliance obligations.”

•   Architectural Relevance This section states the areas that may be impacted by a control. Using AIS-01 as our example, this control is applicable to compute, storage, application, and data. It is not applicable to the physical or network components of a system.

•   Corporate Governance Relevance Is this a governance item, or is it a technical issue? AIS-01 states it is not a governance item.

•   Cloud Service Delivery Model Applicability What service model does this apply to (SaaS, PaaS, IaaS)? AIS-01 applies to all of the service models.

•   Supplier Relationship Who is responsible to implement this control? Is it the provider, the customer, or both? In the AIS-01 example, this is listed as a provider responsibility.

•   Scope Applicability This section maps the control to a wide variety of standards such as NIST, PCI, COBIT, ISO, and more. Using PCI 3.0 as an example (because it’s easiest), we see a mapping between CCM AIS-01 and PCI DSS v3.0 control 6.5.

So now that you understand the basic structure of the document, I want to highlight a couple of items about this document. For your exam, you should know that the biggest reason the CCM is widely followed by companies of all sizes as part of cloud assessments is because of the information covered in the “Scope Applicability” section. The CSA knows this, so you should expect an exam question on it. Don’t bother memorizing all of the mapping possibilities. Second, this is a framework to follow. Just like any other standard out there, the scope is going to require tailoring (or tuning). In other words, the CCM is a great starting point to create assessment checklists based on your compliance requirements, but it is no means complete for every company in every possible scenario.

Consensus Assessments Initiative Questionnaire

Cloud providers can use the CAIQ template to document their security and compliance controls. The structure itself is very close to the CCM with one main difference: the CAIQ contains questions that are very direct and less ambiguous than the control specifications found in the CCM. Take, for example, our AIS-01 control. Here’s the CCM Control Specification wording: “Applications and programming interfaces (APIs) shall be designed, developed, deployed, and tested in accordance with leading industry standards (e.g., OWASP for web applications) and adhere to applicable legal, statutory, or regulatory compliance obligations.”

The CAIQ includes the CCM specification, but it also asks the following four direct questions in a yes-or-no format (there’s also a Notes field that providers often use to expand beyond a simple yes-or-no response):

•   Do you use industry standards (Building Security in Maturity Model [BSIMM] benchmarks, Open Group ACS Trusted Technology Provider Framework, NIST, and so on) to build in security for your systems/software development lifecycle (SDLC)?

•   Do you use an automated source code analysis tool to detect security defects in code prior to production?

•   Do you use manual source code analysis to detect security defects in code prior to production?

•   Do you verify that all of your software suppliers adhere to industry standards for systems/software development lifecycle (SDLC) security?

STAR Registry

The highlight of the STAR registry is its collection of filled-out CAIQ responses from vendors. This repository is freely available, and you can use it to perform a “stealth” inspection of a provider’s security controls before even engaging the provider.

In the following list, I purposefully omitted a few items from the registry because they are out of scope for your CCSK exam. In fact, even the Level 2 discussion is out of scope, but knowing about it is valuable for you as you work with cloud vendors, so I include it here. You will find a few different levels in the STAR registry.

•   STAR Level 1: Self Assessment There is no oversight or third-party inspection regarding what is listed here and what is actually the truth. That said, I like to think that no vendor would be careless enough to list “mistruths” in their STAR entry, because this would eventually be discovered and the vendor would likely suffer tremendous reputational damage. Still, just be aware that it’s called “Self Assessment” for a reason. If you want a third party to sign off on statements, you need to look for the Level 2 STAR entry.

•   STAR Level 2: Third-Party Certification There are actually two ways providers can be listed as having achieved STAR Level 2: STAR Certification or STAR Attestation. The STAR Certification requires that ISO 27001 requirements are followed in a cloud environment being consumed. The STAR Attestation requires that Service Organization Control 2 (SOC 2) criteria are followed. Both require an independent third party having assessed the provider’s environment.

•   STAR Level 3: Continuous Auditing This level is a placeholder for future continuous audit. At this time, it is unavailable to any providers because the standard is still being developed.

Cloud Reference and Architecture Models

Models are tools that you can use to help guide security decisions. The CSA divides these models into four distinct items, or tools, that you can use:

•   Conceptual Models These can include visualizations and descriptions that explain concepts and principles. The logical model (infostructure, applistructure, metastructure, and infrastructure) with what exists at each level is an example of a conceptual model.

•   Controls Models This categorizes and details specific cloud security controls and/or categories of controls. The CCM and ISO 27017 are examples of controls models recommended by the CSA.

•   Reference Architectures Ask ten people what a “reference architecture” is and you’ll get ten different answers. According to the CSA, reference architectures can be anything from a very abstract, high-level concept, to a very detailed concept, down to specific controls and functions. NIST 500-299 (an example architecture diagram shown in Figure 1-7) and the CSA Enterprise Architecture (shown in Figure 1-8) are examples of reference architectures recommended by the CSA.

Figure 1-7   NIST 500-292 reference architecture example. (Source: NIST 500-292.)

Figure 1-8   CSA Enterprise reference architecture example. (Used with permission of Cloud Security Alliance.)

•   Design Patterns These are considered reusable solutions to particular problems. Take, for example, log management in an IaaS environment. You can implement the log management system once and leverage it as part of other systems that are built. Like the reference architecture, a design pattern can be abstract (a box on a diagram) or specific to particular platforms.

Cloud Security Process Model

The following steps are recommended by the CSA as a means to identify a high-level process for managing cloud security. Note that details, controls, and processes are omitted, as this discussion intends to list the activities that should be performed. How you perform them is based on the particular workload. Figure 1-9 graphically shows these steps.

Figure 1-9   Cloud security process model. (Used with permission of Cloud Security Alliance.)

Step 1 Identify required security and compliance controls that must be in place to meet compliance requirements. These requirements will exist no matter where the system is run.

Step 2 Select the cloud service provider, the service model, and the deployment model used. This will assist you in understanding the shared responsibilities.

Step 3 Define the architecture. What components and services will the system use? How can you secure something if you don’t know what it does and what other systems or components it interacts with?

Step 4 Assess security controls. Remember the responsibility of implementing security could be that of the provider, or it may be your responsibility.

Step 5 Identify control gaps. You know what’s required per compliance requirements and what controls are available. Can you find any controls that are required that are not implemented or exposed to you?

Step 6 Design and implement controls to fill the gaps. If the provider doesn’t offer a control that you need, you’re going to have to implement a control to address the gap.

Step 7 Manage changes over time. Security (especially cloud security) is never a one-and-done approach. You have to keep up to date with all changes at the provider side and address any security gaps should they arise.

Chapter Review

This chapter reviewed the foundational information upon which the rest of the book will build from. For your CCSK exam, you must be completely clear on the logical model and, most importantly, the metastructure layer where you will configure and manage a new virtual world through the management plane. Other topics that you can expect to be tested on include the following:

•   Understand the differences between cloud computing and traditional infrastructure or virtualization, and how abstraction and automation impacts security.

•   Know the definitions of cloud computing such as service and deployment models and their associated attributes, inside-out.

•   Become familiar with the NIST model for cloud computing and the CSA reference architecture and how they impact the shared security responsibility model of the cloud.

•   Know how to use the CSA Consensus Assessments Initiative Questionnaire (CAIQ) to evaluate and compare cloud providers.

•   Know how to use the CSA Cloud Controls Matrix to assess and document cloud project security and compliance requirements and controls, as well as who is responsible for each.

•   Use a cloud security process model to select providers, design architectures, identify control gaps, and implement security and compliance controls.

Questions

1.   Which document type is stored in the STAR registry for Level 1 entries?

A.   CCM

B.   CAIQ

C.   Vendor statements of compliance

D.   Government-issued authority to operate letter

2.   Which service model has the provider assuming the most responsibility?

A.   SaaS

B.   PaaS

C.   IaaS

D.   They are all the same as far as responsibility shifts are concerned.

3.   Which logical model holds the management plane that is exposed to customers?

A.   Infostructure

B.   Applistructure

C.   Metastructure

D.   Infrastructure

4.   You are running a web server in an IaaS environment. You get a call from a customer saying the server appears to have been compromised. Which logical model has been impacted?

A.   Infostructure

B.   Applistructure

C.   Metastructure

D.   Infrastructure

5.   Which of the following is NOT an essential characteristic of cloud as per NIST?

A.   Elasticity

B.   Multitenancy

C.   Resource pooling

D.   On-demand self-service

6.   In which logical model would you implement a virtual firewall?

A.   Infostructure

B.   Applistructure

C.   Metastructure

D.   Infrastructure

7.   How is one consumer’s access tightly isolated from other consumers in a public cloud environment?

A.   Strong passwords

B.   RBAC

C.   Policies at the provider side

D.   Policies at the customer side

8.   Orchestration enables a controller to request resources from a pool of resources. How is this done?

A.   Ticketing system prioritizes clients based on support level

B.   Through the use of REST APIs

C.   Through the use of RPC

D.   Via network calls

9.   You are instructed to build a server with eight CPUs and 8GB of RAM. Which service model would you use?

A.   SaaS

B.   PaaS

C.   IaaS

D.   No cloud provider supports a machine with 8 CPUs

10.   Your company is using a PaaS provider to host a Python 2.7–based application. One day, the provider sends you an e-mail stating they will no longer support the Python 2.7 platform and all applications must be upgraded to use Python 3.6 within two weeks. What is the first action you should take?

A.   Test the application in Python 3.6.

B.   Tell the provider you can’t meet this timeline.

C.   Providers are restricted by law from doing this.

D.   Launch a lawsuit against the provider for pain and suffering.

Answers

1.   B. Providers will upload copies of filled-out CAIQ responses. Although ISO and/or SOC can be used as part of a Level 2 STAR entry, Level 1 entries use the CAIQ, not the CCM.

2.   A. The SaaS service model has the provider assuming responsibility for most (not all) controls.

3.   C. The management plane is part of the metastructure logical model.

4.   B. The web server is part of the applistructure. The controls surrounding the web server would be implemented at the metastructure level, but the web server itself is at the applistructure level (and data is at the infostructure layer).

5.   C. NIST doesn’t call out multitenancy as an essential characteristic. ISO, however, does call out multitenancy as part of the resource-pooling essential characteristics.

6.   C. All controls in the virtual environment are performed at the metastructure layer. If the question asked about installing a firewall agent, that would occur at the applistructure layer.

7.   C. Tenants are protected by policies at the provider side. Consider, for example, network sniffing. One tenant will never see network traffic destined for another tenant. As a general rule, one tenant should never know that another tenant even exists. Although consumers will also have their own policies in place, the provider must ensure that there is strong isolation of workloads and tenants. This makes C the best answer.

8.   B. Orchestration generally uses REST API calls. Although orchestration is, of course, performed across a network, the best answer is REST API calls. This is an example of the tricks that test writers like to pull on candidates.

9.   C. This is a prime example of why you would use IaaS—access to core foundational computing.

10.   A. When a platform is deprecated (no longer supported), the provider will generally give you access to a test environment where you can test your application using the new platform. As for the time provided in the question, it’s a bit extreme based on what I’ve experienced, but there is no law stopping a provider from giving you hours to migrate, let alone weeks.