The Official (ISC)2 CCSP CBK Reference. Leslie Fife

Shared Responsibility Model for cloud services is commonly presented by the major vendors, which are all similar. There is an architecture stack. Some items in the stack are the responsibility of the CSP, and some are the responsibility of the customer. In between, there is an area of varied responsibility. At times, this middle area is the responsibility of the CSP and sometimes of the customer and sometimes both. It is important for the customer to know their responsibilities, especially in this middle region.

      A typical architecture stack looks like this:

       Data

       APIs

       Applications/solutions

       Middleware

       Operating systems

       Virtualization (VMs, virtual local area networks)

       Hypervisors

       Compute and memory

       Data storage

       Networks

       Physical facilities/data centers

      It is generally understood that the CSP is responsible for the last five items on the list in all delivery models. However, where the line between customer and CSP exists varies beyond that.

      The exact split and layer names vary by vendor, but the general principle remains the same. Both the CSP and the customer have some individual security responsibilities, and along the line where these meet, each may have some security responsibilities. The line for each delivery model is explained in the following sections.

      Software as a Service

      From a security standpoint, you have limited security options with a SaaS solution. Most of the security options are provided by the SaaS provider. The SaaS provider is responsible for the security of the infrastructure, operating system, application, networking, and storage of the information on their service.

      In the Shared Responsibility Model, the customer is responsible for their data and may have some responsibility for the APIs. All other layers are the responsibility of the CSP.

The user of a SaaS solution has responsibilities as well. When a service is subscribed to by an organization or an individual, it is important to understand the security policies and procedures of the SaaS provider to the extent possible. In addition, the user determines how information is transferred to the SaaS provider and can do so securely through end-to-end encryption. The SaaS user is responsible for determining how the data is shared. Finally, the user can provide access security through proper use of login credentials, secure passwords, and multifactor authentication when available.

      Platform as a Service

      In a PaaS solution, security of the underlying infrastructure, including the servers, operating systems, virtualization, storage, and networking, remain the responsibility of the PaaS service provider. The developer is responsible for the security of any solutions developed, and the data used by their application, as well as the user responsibilities of a SaaS application regarding user access and use of the solutions developed.

      In the Shared Responsibility Model, this means the customer is responsible for the data, APIs, and applications, with potentially some middleware responsibility.

      Infrastructure as a Service

      IaaS security leaves most of the responsibility of security with the customer. IaaS service providers secure the portions they are responsible for. These areas include the servers, virtualization, storage, and networking. The IaaS customer is responsible for the security of the operating system and everything built on top of it, including the responsibilities of a PaaS and a SaaS implementation.

      In the Shared Responsibility Model, the customer is responsible for everything above the hypervisor. As in the other delivery models, the exact responsibility along this line can vary between the CSP and customer and must be clearly understood in each case.

EVALUATE CLOUD SERVICE PROVIDERS

      Evaluation of CSPs is done through objective criteria. This becomes simpler if those criteria are a known standard. Standards are voluntary for some and required for others. However, the use of a standard makes comparisons between products and services more straightforward.

      For example, FIPS 140-2, Federal Information Security Management Act (FISMA), and NIST standards are required for those working with the U.S. federal government. PCC DSS is contractually required by those accepting credit card payments.

Federal Information Processing Standards (FIPS), FISMA, and NIST may have been chosen as the standard in some industries but are suggestions and guidelines for everyone else. Internationally, Common Criteria and ISO standards have been chosen as required by some organizations, industries, and countries and serve as recommendations and guidelines for everyone else.

      Verification against Criteria

      Difference organizations have published compliance criterion. For cloud computing, these are currently regulatory or voluntary standards. The International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) standard is voluntary but may be necessary to work in some parts of the world and may prove advantageous even when not required. PCI DSS is a contractual requirement. The Payment Card Industry (PCI) Security Standards Council publishes the criteria that are required if you are a vendor that wants to accept credit cards as payment.

      International Organization for Standardization/International Electrotechnical Commission

      ISO/IEC 27017 and 27018 provide guidance for the implementation of cloud security and the protection of personally identifiable information (PII). 27017 added 35 supplemental controls and extended seven existing controls to the original ISO documents. Most CSPs were already compliant with these additional controls or could easily add them. Becoming compliant with this new standard is straightforward

      ISO/IEC 27018 serves as a supplement to ISO 27002 and is specifically geared toward PII processors. Like 27017, these principles are recommendations and not requirements. 27018 added 14 supplementary controls and extended 25 other controls. As an international standard, adherence to this standard will help an organization address a wide and ever-changing data protection and privacy environment stretching from GDPR in the EU to standards in Russia, Brazil, the Philippines, and elsewhere around the globe.

      While these are recommendations and not requirements, many international corporations strive to be ISO-compliant. In that case, the criteria provided by ISO/IEC become the governing principles of the organization, including the reference framework, cloud service models (of which there are seven instead of just SaaS, PaaS, and IaaS), and the implementation of controls from the approved control set. Auditing the controls and conducting a risk assessment should help identify which controls best address identified risk.

The ISO standard is important for companies in the international marketplace. These standards have wide acceptance throughout the world. These standards also provide an excellent framework for developing cloud services. Cloud services, because of their broad network access, are more international than many traditional IT services. An international standard is an important consideration.

      Payment Card Industry Data Security Standard

      The Payment Card Industry Data Security Standard released version 3.2.1 of PCI DSS in 2020. PCI is contractual compliance between the major credit card companies and the vendor. All cloud customers that accept credit cards must comply with all 12 requirements.

      In the 12 requirements, the cloud is referenced in only one place and refers to the appendix for shared hosting requirements. These requirements can be summarized as follows:

       Ensure