Document Diff - PCI Watch

Added p. 2

Document Changes Date Version Description

Added p. 2

April 2018 3.0 Updated PCI SSC Guidelines for Secure Cloud Computing, produced by 2017 Cloud SIG. Changes include:

• Restructure of the document for better flow (e.g., consolidation of Sections 6.3 and 6.4, and moving Section 6.5 to Appendix E).

• Updated guidance on roles and responsibilities, scoping cloud environments, and PCI DSS compliance challenges.

• Expanded guidance on incident response and forensic investigation.

• New guidance on vulnerability management, as well as additional technical security considerations on topics such as Software Defined Networks (SDN), Containers, Fog Computing and Internet of Things (IoT).

• Standardized terminology throughout the document.

• Updated references to PCI SSC and external resources.

• Minor grammatical updates.

Added p. 5

This guidance is intended for organizations using, or thinking of using, providing or assessing cloud technologies. It provides guidance on the use of cloud technologies and considerations for maintaining security controls in cloud environments. This document is intended to provide an initial point of discussion for Providers and Customers and is not intended to address specific technical configurations or compliant scenarios.

• Cloud Provider/Customer Relationships

• Discusses how roles and responsibilities may differ across different cloud service and cloud deployment models.

• PCI DSS Considerations

• PCI DSS Compliance Challenges

• Security Considerations

• Appendix A: PCI DSS Responsibilities for Different Service Models

• Appendix B: Sample Inventory

• Appendix C: PCI DSS Responsibility Management Matrix

• Appendix D: PCI DSS Implementation Considerations

• Appendix E: Technical Security Considerations

• Provides guidance on various cloud-based technologies.

Added p. 6

• Guidance on the security and PCI DSS considerations that are applicable to cloud environments and may be useful to merchants managing their own cloud infrastructure as well as those looking to engage with a third party. Guidance for working with third-party Providers and PCI DSS compliance challenges may also be useful.

• Guidance on the security and PCI DSS considerations that may provide useful information for Providers to assist their understanding of the PCI DSS requirements, and may also help Providers to better understand Customers’ PCI DSS needs. The guidance on Provider/Customer relationships and PCI DSS compliance challenges herein may also be useful for Providers.

• Cloud Service Provider ("Provider"): It is the entity providing the cloud service. It acquires and manages the infrastructure required for providing the services, runs the cloud software that provides the services and delivers the cloud services through network access.2

• Cloud Service Customer ("Customer"): The entity …

Added p. 7

Ensuring that cloud services are designed, maintained and used securely is a shared responsibility between the Provider and the Customer. It is important to note that all cloud services are not created equal. Clear policies and procedures should be agreed upon between the Customer and the Provider for all security requirements. Responsibilities for operation, management and reporting should be clearly defined and understood for each requirement and acknowledged, in writing, in contractual agreements.

Regarding third-party or public clouds, Customers should consider that while they can outsource the day-to- day operational management of the data environment, they retain responsibility for the data they put in the cloud. Customers are encouraged to "shop around" until they find a Provider who can provide the level of security and assurance they require.

The following steps should be followed by any organization looking to migrate to or evaluate cloud services:

• UNDERSTAND your risk and security requirements first.

• …

Added p. 9

• Public cloud: Cloud deployment model where cloud services are potentially available to any Customer and resources are controlled by the Provider. A public cloud may be owned, managed and operated by a business, academic or government organization, or some combination of them. It exists on the premises of the Provider. Actual availability for specific Customers may be subject to jurisdictional regulations. Public clouds have very broad boundaries, where Customer access to public cloud services has few, if any, restrictions.

• Private cloud: Cloud deployment model where cloud services are used exclusively by a single Customer and resources are controlled by that Customer. A private cloud may be owned, managed and operated by the organization itself or a third party and may exist on premises or off premises. Private clouds seek to set a narrowly controlled boundary around the private cloud based on limiting the customers to a single organization.

• Community …

Added p. 10

• The cloud infrastructure is a composition of two or more clouds (private, community or public) that remain unique entities but are bound together by technology to enable portability. Hybrid clouds are often used for redundancy or load-balancing purposesfor example, applications within a private cloud could be configured to utilize computing resources from a public cloud as needed during peak capacity times (sometimes called "cloud-bursting").

Added p. 10

There are other standards and frameworks that define different vocabulary and reference architecture (e.g., ISO/IEC 17788:2014) which are mostly comparable with the terms and categories defined by NIST. For consistency, this guidance document uses NIST terminology (i.e., SaaS, PaaS and IaaS) to describe the service categories of Provider services.

Added p. 11

Figure 1: Level of control/responsibility for Customer and Provider across different service categories The level of security responsibility across the cloud service categories generally migrates towards the Customer as the Customer moves from a SaaS category (least Customer responsibility) to an IaaS category (most Customer responsibility). The greatest level of responsibility for the Provider to maintain security and operational controls is present in the SaaS service category.

While Customers may be attracted to the SaaS and PaaS categories due to the resource savings and reduced responsibility for administering the cloud environment, they should be aware that these categories also correspond to a greater loss of control of the environment housing their sensitive data.

Contractual agreements and ongoing due diligence become especially critical where control is outsourced, to ensure that the required security measures are being met and maintained by the Provider for the duration of the agreement.

It is important to note that …

Added p. 13

Table 1 illustrates how control of the different technical layers is often shared across different cloud service categories. For illustration purposes, different layers of the cloud stack are described as follows:

Added p. 14

Table 1: Example of how control may be assigned between Provider and Customer across different cloud service categories Responsibility Service Models IaaS PaaS SaaS Security Governance, Risk and Compliance (GRC) Customer Customer Customer Data Security Customer Customer Customer Application Security Customer Customer Shared Platform Security Customer Shared Provider Infrastructure Security Shared Provider Provider Physical Security Provider Provider Provider

Some Providers offer multiple options for their servicesfor example, a Provider may have one IaaS offering that includes a Customer-controlled hypervisor and a separate IaaS offering with no Customer access to the hypervisor. It is imperative that Customers and Providers clearly document and understand where the boundaries are in their particular relationships, rather than assuming that any particular responsibility model applies to them.

Even where a Customer does not have control over a particular layer, it may still have some responsibility for the configurations or settings that the Provider maintains on its behalf. For …

Added p. 15

An example of nested service provider relationships is illustrated in Figure 2 below:

Figure 2: Example of nested service provider relationships Information Supplement

• Provider 1 relies on Provider 2 for web content delivery services and Provider 3 for media streaming, as well as Provider 1.5 (internal/private cloud) for PaaS.

• Provider 4 provides SaaS service to both Providers 2 and 3.

• Provider 5 provides IaaS service to Provider 3.

There may be multiple layers or levels of Provider dependency, which can affect the security of the cardholder environment. Identifying all third-party relationships that the Provider has in place is important in order to understand the potential ramifications for a Customer’s environment. The existence of multiple nested relationshipsfor example, where there is a chain of vendors and other Providers required for delivery of a cloud servicewill also add complexity to both the Provider’s and the Customer’s PCI DSS assessment process.

Where the Customer has a …

Added p. 20

SECaaS can vary in complexity from a relatively simple cloud-based application subscription model to complex outsourcing of entire security functions such as a Security Operation Center (SOC) or a Network Operation Center (NOC) using cloud-delivery models. The number of applicable PCI DSS requirements that fall under the responsibility of the SECaaS Provider will increase relative to the complexity of the service being provided. Merchants using SECaaS must include SECaaS service providers in the list of PCI service providers, and ensure compliance with, at the very least, PCI DSS Requirements 12.8.1

• 12.8.5 for each SECaaS service provider used.

Added p. 20

In addition to enforcing separation between Customer environments, segmentation may also be desired within a Customer’s environment to isolate its CDE components from non-CDE components in order to reduce its own PCI DSS scope.

Segmentation on a cloud-computing infrastructure must provide a level of isolation equivalent to that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system and application layers; and most importantly, there should be guaranteed isolation of data that is stored (see Section 4.4.3, “Segmentation Technologies,” for more information). Cloud tenant environments must be isolated from each other such that they can be considered separately managed entities with no connectivity between them. Providers should test segmentation (Requirement 11.3.4) between all entities within their control at least semiannually and demonstrate results.

Any systems or components shared by the Customers in multi-tenant environments, including the hypervisor and underlying systems, must not provide an …

Added p. 21

A segmented cloud environment exists when the Provider enforces isolation between Customers in multi- tenant environments. Examples of how segmentation may be provided in shared cloud environments include, but are not limited to:

• Traditional Application Service Provider (ASP) model, where physically separate servers are provided for each Customer’s cardholder data environment (CDE)

• Virtualized servers that are individually dedicated to a particular Customer, including any virtualized storage such as Storage Area Networks (SANs), Network Attached Storage (NAS) or virtual database servers

• Environments where Customers run their applications in separate logical partitions using separate database management system images and do not share disk storage or other resources The PCI DSS assessor must validate the effectiveness of the segmentation to ensure that it provides adequate isolation. If adequate segmentation is provided between the cloud tenants (in a multi-tenant environment), only the Customer environment and the Provider-managed environment and processes would be in scope …

Added p. 22

In a private cloud environment, one approach that may help reduce the complexity of segmentation efforts could be to locate all CDE virtual components on a dedicated CDE hypervisor, and ensure that all non-CDE virtual components are located on separate hypervisors, adequately segmented from the CDE hypervisor.

The need for adequate segmentation of Customer environments in a public or shared cloud is underscored by the principle that the other cloud tenant environments running on the same shared infrastructure are to be considered untrusted networks. The Customer has no way of confirming whether other cloud tenant environments are securely configured or patched appropriately to protect against attack, or that they are not already compromised or even designed to be malicious. This is particularly relevant where a Provider offers IaaS and PaaS services, as the individual Customers have greater control and management of their environments.

Added p. 22

Customers wishing to implement segmentation within their cloud environments also need to consider how the Provider’s environment and processes may affect the effectiveness of the segmentation. For example, Provider systems could be providing connectivity between the Customer’s own VMs that is not visible to the Customer. Customers should also consider how the Provider manages offline or dormant VMs, and whether in-scope and out-of-scope VMs could potentially be stored together by the Provider without active segmentation controls.

Added p. 22

This would require hypervisors with multiple network interfaces and with configurations that meet PCI DSS requirements for the various types of network hardware. Additionally, virtual counterparts of firewalls, switches and routers now exist and can be incorporated into a virtual environment.

As mentioned above, a key consideration is how secure the common layers (such as hypervisors, container implementations and shared physical components) are, and to what extent they represent a potential attack surface between zones or Customers.

• Firewalls and network segmentation at the infrastructure level

• Firewalls at the hypervisor and VM level

• VLAN tagging or zoning in addition to firewalls

• Software Defined Networks (see Section E.4, “Software Defined Networking,” for additional information)

• Intrusion prevention systems at the hypervisor level, VM level or both, to detect and block unwanted

• Data-loss-prevention tools at the hypervisor level, VM level or both

• Controls to prevent out-of-band communications occurring via the underlying infrastructure

• Isolation of shared …

Added p. 24

• Usage of PCI-listed P2PE solutions may help to reduce PCI DSS scope. While a PCI-listed P2PE solution does not completely remove the need for PCI DSS validation of the payment acceptance environment, the Customer back-end environments could potentially be considered out of scope.

• Use other technologies to reduce exposure and devalue the payment card data, such as tokenization.

Customers should be aware of and understand the scope impact of various cloud-based encryption and tokenization solutions11for example, those outsourced to the cloud, products developed in-house or off- the-shelf products. o Third-party cloud-based solutions could potentially limit the Customer's exposure to a clear-text primary account number (PAN), as payment card data can be stored with the Provider, and not by the Customer itself. o In-house hosted solutions, whether custom developed or off-the-shelf encryption or tokenization products, require the entity to protect the stored cardholder data within the solution, and will likely involve …

Added p. 25

For more information, refer to the Information Supplement Guidance for PCI DSS Scoping and Network Segmentation, which is intended to provide further understanding of scoping and segmentation principles as applicable to the PCI DSS environment.14 4.5.1 Security of Cloud Service Customer Systems Customer systems used to access the cloud environment such as workstation, smartphone and Internet of Things (IoT) device, should not be overlooked, as they could potentially become weak links in a Customer’s cloud security strategy. Customers need to ensure that their systems and internal processes do not provide unauthorized access to the cloud environment. For example, if a Customer workstation or other device is compromised, an attacker may be able to use credentials and an authorized channel to gain access to the cloud environment from the compromised Customer system. The Customer will therefore need to ensure that its Customer-side devices are appropriately secured and protected from unauthorized physical …

Added p. 26

• All VMs or containers are hosted on one or more hypervisors or servers; some VMs transmit, process or store cardholder data and are considered CDE systems, and some do not process, transmit or store cardholder data or are not required to communicate to the CDE systems.

• One or more containers running within one or more dedicated container orchestration servers

• Validated segmentation of Customer environments using a combination of physical and logical controls The Provider is responsible for compliance of all elements of each underlying PCI DSS compliant cloud service provided to the Customer. Each Customer’s scope would include its own environment (e.g., VMs, applications, etc.), the user and system configuration and management of the Provider services (Customers' access controls, etc.), and any other elements not managed by the Provider. Segmentation must be validated as providing effective isolation between Customers as part of the Provider’s validation and may require additional …

Added p. 31

High confidence is placed in the statement "I am PCI DSS compliant," but what does this actually mean for the different parties involved? Use of a PCI DSS compliant Provider does not automatically result in PCI DSS compliance for the Customers. The Customer should confirm that the Provider is PCI DSS compliant and that the services used by the Customer were included in the Provider's PCI DSS compliance validation (see Section 5.2, “Verifying the Scope of PCI DSS Validated Services and Components”). Moreover, the Customer must still ensure that it is using the service in a compliant manner and is also ultimately responsible for the security of its CHDoutsourcing daily management of a subset of PCI DSS requirements does not remove the Customer’s responsibility to ensure that CHD is properly secured and that PCI DSS controls are met. The Customer therefore must work with the Provider to ensure that evidence …

Added p. 32

The following questions may be useful for Customers to ask their Providers:

• For each service used by the Customer, which PCI DSS requirements were included in the validation?

• Was the compliance validation conducted by a PCI-qualified and trained assessor (e.g., QSA or ISA)?

• Has the Provider supplied information (for example, a Responsibility Matrix) to Customers that clearly delineates the PCI DSS requirements met on behalf of the Customer?

• How does the Provider ensure that Customers using the PCI DSS compliant service cannot introduce non- compliant components to the environment or bypass any PCI DSS controls? Providers should provide their Customers with evidence that clearly identifies the scope of their PCI DSS assessment, the specific PCI DSS requirements that the environment was assessed against and the date of the assessment. The Customer must have a detailed understanding of any security requirements that are not covered by the Provider and are therefore …

Added p. 35

A responsibility matrix would be an appropriate approach to clearly define the governance strategy in the cloud, particularly when documented in the SLA. This enables clarity of responsibilities between Customer and Provider for operational security and risk management. Reporting and monitoring mechanisms should be made available by the Provider to its Customers to provide assurance that effective governance is applied and maintained by the Provider throughout the service. Examples of reports include, but are not limited to:

• Internal audit reports

• Independent audit reports

• Vulnerability and penetration testing reports

• Risk and vulnerability remediation action plan 6.1.1 Risk Management Consistent with a risk management approach for in-house services, outsourced cloud services should be assessed against an organization’s risk strategy with the intent of identifying critical assets, analyzing potential risks to those assets and developing an appropriate risk treatment plan.

In traditional environments, the physical location of sensitive data can be restricted to dedicated …

Added p. 36

• Understanding the Provider's operational responsibilities, such as incident response, encryption and security monitoring

Performing a due-diligence exercise prior to engagement with the Provider does not remove the need to perform an ongoing monitoring and review of the services offered by the Provider.

Added p. 38

• Retained for as long as needed

• Not retained any longer than needed

• Stored only in appropriate and secured locations

• Accessible only to those with a business need

Added p. 39

Other legal considerations include requirements for electronic discovery, evidence preservation and integrity, and data custody. Providers should have documented processes for responding to legal requests for seizure of records, including data/audit logs belonging to the Provider and its Customers.

Customers should understand the ramifications of such laws in the countries where their data exists, as well as the processes in which their Provider will engage.

Added p. 40

In addition to data disposal, resource-decommissioning requirements should be defined to support Customers’ future decisions to migrate to a new Provider, decommission their cloud resources or move out of a cloud environment altogether. The Provider should provide data-disposal mechanisms that Information Supplement

Added p. 41

Customers may choose to ensure that all data is encrypted with strong cryptography (see Sections E10, “Data Encryption and Cryptographic Key Management,” and E.11, “Secure Cryptography Devices in the Cloud,” for further information) to reduce the risk to any residual data left behind on Provider systems.

However, Customers should be aware that leaving potentially unknown quantities of encrypted data on Provider systems after their agreement has been terminated is likely to be a violation of their data- retention policy.

Added p. 41

Customers should work with their Providers to document security incident response, forensics and data breach notification-related roles and responsibilities as part of SLAs and contractual agreements, taking into consideration the need to comply with security incident management (i.e., PCI DSS Requirements 12.5.3, 12.8.3 and 12.10) and service provider requirements (i.e., PCI DSS Requirement 12.9).

Added p. 42

Section 6.3.1.3, “Data Sovereignty and Legal Considerations”).

Forensic functionality should be specified in service level objectives (SLOs) incorporated into the SLA between the Customer and the Provider. SLOs may include requirements for notification, identification, preservation and access to potential evidence sources.17 Customers and law enforcement agencies require, and rely on Providers for, forensics support, and these obligations varies depending upon cloud service category as noted below.18

• SaaS: The capability for forensics is dependent upon the Provider’s support, as Customers have no control over the Provider’s environment. Forensics examiners may need to rely on high-level application logs available from the SaaS application. SLOs may include evidence sources such as logs from applications, web, database server, guest OS/host, portal, network capture and billing systems.

• PaaS: The capability for forensics is shared between Customers and Providers. Customers control the developed and hosted software application, and hence control forensics capability within the application, automatic logging …

Added p. 42

June 2013). https://downloads.cloudsecurityalliance.org/initiatives/imf/Mapping-the-Forensic-Standard-ISO-IEC-27037-to- Cloud-Computing.pdf.

Categories of data and security incidents should be prioritized with expected timelines for notification depending on incident type and requirements by the Customer, and where required, should include:

• Defined breach notification response responsibilities and obligations

• Customers' contact information (e.g., email in lower priority incidents, or 24/7 incident response call number for high priority incidents)

• Rights to involve Customer’s or card brand forensic teams in the investigation of an incident or breach Similarly, Providers may want to contractually require their Customers to inform them of any suspected or actual compromisefor example, breach of authentication credentials or identified service vulnerabilities.

When an incident notification is received by the Provider or Customer, it is that party's responsibility to follow the implemented incident response plan (per PCI DSS Requirement 12.10). In addition, Providers are required to perform reviews at least quarterly to confirm that personnel are following established processes to respond to …

Added p. 43

PCI DSS are six distinct areas of vulnerability management: web application vulnerability testing (PCI DSS

Requirement 6.6), internal network vulnerability scanning (PCI DSS Requirement 11.2.1), external network vulnerability scanning (PCI DSS Requirement 11.2.2), external penetration testing (PCI DSS Requirement 11.3.1), internal penetration testing (PCI DSS Requirement 11.3.2) and segmentation testing (PCI DSS

Scoping is a critical element of vulnerability management. Customers need to ensure that they have properly identified all in-scope systems and services, including those provided by the Provider, those for which the Customer and Provider have shared responsibility and those that fall uniquely to the Customer (e.g., on- premises, private cloud, hybrid systems, or applications or systems that the Customer maintains). Penetration testing is used to confirm segmentation controls intended to constrain scope, and to proactively identify vulnerabilities that could be exploited to allow an attacker to breach these boundaries.

Testing vulnerabilities in the cloud also requires an in-depth understanding of …

Added p. 44

For applications that are supplied by the Customer (e.g., a microservice running on a PaaS or IaaS service), it is the Customer’s responsibility to perform the web application vulnerability security testing as a part of its PCI compliance program. Providers should recognize this requirement and support these required testing activities (e.g., by supporting the ability to disable controls that would impede controlled testing, by supporting applications that may perform these operations or offering a service to perform these services).

Added p. 45

Validation testing should include tests between VMs/instances, between applications/microservices hosted in separate virtual networks.

The Provider should perform penetration testing as part of its own PCI DSS assessment to demonstrate separation of client networks, in order to aid Customers in meeting this requirement.

These should include tests between Provider management nodes and Customer systems, and between Customers on shared infrastructure. This testing should be used to verify that adequate restrictive network controls are in place to segregate the environments (e.g., assessing the effectiveness of the restricted network controls implemented at the security groups/firewall or ACLs).

Added p. 46

Notification may include anticipated testing dates, types of testing and details such as IP address range(s) affected. It is also important for the Customer to understand what testing activities are permitted by the Provider, and ensure that such activities do not harm other Customers within the environment. Any such constraints should be detailed in the Service Contracts, Terms of Service or Acceptable Use policy.

Appendix A: Sample PCI DSS Responsibilities for Different Cloud Service Categories This Appendix expands on Table 2 (in Section 4) and provides examples of the ways in which responsibilities for PCI DSS requirements may be shared between Customers and Providers across some of the various cloud service categories. There will of course be exceptions and variations across each individual service, and this table is provided as a guideline for Customers and Providers to help plan discussions and negotiations.

The descriptions in this table are intended to reflect the …

Added p. 56

PCI DSS Requirement Responsibility (Provider only, Customer only, or shared) Specific Coverage/ Scope of Customer Responsibility Specific Coverage/ Scope of Provider Responsibility How and When Provider Will Provide Evidence of Compliance to Customer 1.1.3 Current diagram that shows all cardholder data flows across systems and networks 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone 1.1.5 Description of groups, roles, and responsibilities for logical management of network components …And so on.

Note: This is intended as an example only to provide a starting point for discussions between Customers and Providers. It is not intended as a requirement or an extension of PCI DSS compliance responsibilities. However, it may provide a useful tool to help to clarify responsibilities in agreements between Customers and Providers.

Appendix D: PCI DSS Implementation Considerations The questions in this appendix are intended as suggestions to help start …

Added p. 65

E.3 Internet of Things and Fog Computing "Smart" devices, such as mobile phones, tablets, wearables, smart sensors and IoT devices are increasingly used to accept and process payments. While these devices rely on the cloud-based ecosystem, they often use fog computing ("fog") as a layer between themselves and the cloud back Fog computing or fog networking is an emerging architecture for computing, storage, control and networking that distributes these services closer to end-users along the cloud-to-things continuum.21 From an architectural standpoint, fog provides computing resources closer to the data-producing end- points at the edge. Devices in the fog computing (fog nodes) tend to be in a widely distributed deployment, with a very large number of nodes positioned for ingestion and processing of the data close to the source (i.e., IoT devices), providing interplay with the cloud back end.

Fog computing can be seen as an extension of the traditional cloud-based computing …

Added p. 66

Traditional Defined Network Software Defined Network Figure E-1: Comparison of SDN and traditional networking SDN environments should be evaluated in a consistent manner whether they are provided by an external Provider (in a public or hybrid cloud scenario) or an internal Provider (in an on-premises private cloud scenario). The SDN Provider must maintain a separation of duties from the SDN consumer (whether an external Customer or a business unit within an organization), even if they are in the same organization, to ensure that the SDN Provider is not able to alter the network topology or rules outside what is agreed upon with the Customer.

In multi-tenancy SDN environments, SDN consumers should be logically separated from each other within the SDN, and each SDN consumer should only be able to update the network policies applicable to its systems, and should not have visibility to the policies managed by other SDN consumers.

Typical evidence …

Added p. 69

Providers can leverage products that provide Virtual Machine Introspection (VMI, also referred to as Guest Introspection). Providers have marketplaces with security products, such as those for AV, IPS and FIM, that provide protection from a central source appliance to virtual machines with minimal or no agent implementations. These products produce logs that can be reviewed by security information and event management SIEMs and participate in an alerting implementation.

E.7 Containers Containerization is an increasingly popular technology for efficiently running many instances of a server or application. It has resource, security and security isolation properties similar to those of virtual machines, but not the memory and performance overhead inherent in system-level hypervisors. Container orchestration platforms are becoming an increasingly popular service offering that allows Customers to spin an instance or a swarm of containers, and dynamically control the computing output capacity.

Added p. 70

Containers are designed to be deployed as very lightweight, short-lived groups of systems. This provides speed and scalability by increasing the quantity of containers in the group dynamically.

Because of this, controls should focus on the image templates and group as an aggregate, not the individual containers within the group.

Organizations should examine their container orchestration technology to confirm that it includes at least the following:

• Access controls to both the orchestration framework and the containers themselves such that different workloads do not have access to keys, identity tokens and other sensitive information used by other containers in the cluster.

• Process isolation of the running containers based on industry standard technologies such as kernel namespaces () and CGroups(). Best practices include controls to enforce kernel permission checks on privileged processes (sometimes referred to as capabilities).

• Access restriction of containers to host file systems and access restriction to container file systems by other …

Added p. 71

• Where supported by the application, read-only containers should be used.

As containers can be used to achieve a similar level of execution, organizations may choose to use them to segment their PCI DSS scope in a manner similar to virtual machines. The Customer must validate that the container orchestration technology or solution offered by the Provider has all the features required to fully isolate containers. If isolation of workloads within a cluster cannot be assured through technical controls, the Customer should consider deployment of workloads into separate, workload-specific clusters. Some Providers may deliver the ability for an individual Customer to orchestrate multiple clusters, but some Providers may not offer this, and all workloads are deployed into shared, mixed workload clusters. In the latter case, a Customer may need to consider workload-specific Customer accounts to provide the isolation necessary.

Validating that a container solution has the necessary isolation strength in place will …

Added p. 73

E.9 Elastic Resources Inventory and Control Cloud architectures that are designed to elastically scale can present challenges that affect several

PCI DSS Requirements, including Requirements 2.4, 6.4, 10.2.7, 11.3.1 and 11.3.2, among others. In order to best evaluate adherence of elastically generated environments to the requirements of the

PCI Data Security Standard, an organization should assess the controls around the scaling automation.

• The template images from which elastic resources are instantiated should be reviewed for adherence to system configuration standards and security controls (e.g., PCI DSS Requirements 2.1, 2.2 and 5.1).

• The environment to which elastic resources are deployed should be evaluated for adherence to network segmentation rules (e.g., PCI DSS Requirements 1.2, 1.3 and 7.2).

• Because the inventory of system components (as required by PCI DSS Requirement 2.4) can change dynamically, the elastic automation should log all system creation and destruction activities to provide the ability to report on the inventory …

Added p. 74

• The system should be able to provide a snapshot report of the currently deployed inventory (PCI DSS Requirement 2.4) to compare against the log files as a demonstration of inventory audit integrity.

• As an alternative to reviewing change management (PCI DSS Requirement 6.4) around individual elastic events, an organization could review the change management around the rules that govern elastic events, and the change management around the automation systems including the template images and the provisioning systems.

• Administration of the elastic automation, including development of the elastic automation pipeline, should be reviewed for strong authentication control and audit of activities (PCI DSS Requirements 8.1, 8.2 and 8.3).

• Consider including a vulnerability scan at the start of an instance, container API or service launch to provide a record of the artifact and a review of change impact.

• Penetration tests (PCI DSS Requirement 11.3) should include the provisioning and orchestration automation …

Added p. 76

Where the Customer uses keys generated by the SCD, it is responsible for documenting the key usage, custodianship, access controls and protection mechanisms after the keys have been retrieved.

In addition to PCI DSS, there are other PCI SSC programs that have stringent requirements for the use of SCDs that meet specific industry certifications; e.g., PCI PTS HSM v2 and FIPS 140-2 level 3.

Examples of current standards that include SCD hardware stipulations include PCI P2PE, PCI PIN,

PCI TSP, PCI SPoC, and PCI 3DS Core Security Standard. Furthermore, the requirements for these programs may impose additional physical and logical security requirements related to the protection of approved devices. Entities subject to these requirements should confirm that the Provider has been assessed to all relevant physical security requirements necessary to achieve compliance to applicable standards. Similarly, Providers may wish to proactively understand and implement the relevant security controls for these PCI programs if …

Added p. 77

When consuming APIs exposed by a Provider, it is important to ensure that all applicable PCI DSS requirements are met. For example, all API calls affecting cardholder data and the cardholder data environment must be logged and reviewed per PCI DSS Requirement 10. Or, when invoking a web services call that transmits cardholder data, it should be over an encrypted tunnel (e.g., SOAP native encryption or a TLS tunnel).

The use of a single Customer credential that covers multiple cloud services for that Customer is also a potential concern. For example, let us say that a Provider issues a Customer a user account and password that has administrator privileges in one environment and user-level privileges for a separate, unrelated cloud service. Compromise of the Customer’s user-level account in the second environment could therefore result in the attacker gaining administrator-level access to the first environment. Customer accounts and passwords should be unique …

Added p. 78

E.15 Logging and Audit Trails The ability to maintain an accurate and complete audit trail may require logs from all levels of the infrastructure, requiring involvement from both the Provider and the Customer.

For example, the Provider could manage system-level, operating system and hypervisor logs, while the Customer configures logging for its own VMs and applications. In this scenario, the ability to organize various log files into meaningful events would require correlation of Customer-controlled logs with those controlled by the Provider.

Providers are responsible for providing log data for resources managed by the Provider (for example, logs for infrastructure components (IaaS), logs for platform components (PaaS), logs for software components (SaaS), etc.). Providers should be able to segregate log data applicable to each Customer and provide it to each respective Customer for analysis without exposing log data from other Customers. In addition, the Provider must implement controls to protect the collected log …

Added p. 79

The 2017 Cloud SIG consists of representatives from the following organizations:

Added p. 79

AccorHotels Acumera, Inc.

Advam Pty Ltd Air Liquide USA LLC Allstate Insurance AT&T Consulting services Ather Technology Limited, dba Cianaa Technology Automobile Club of Southern California Bank of America N.A.

Bank of Montreal Barclaycard Basefarm A/S BCD Travel BDO USA, LLP Beijing UGTech Co. Ltd.

Bravecraft (Pty) Ltd BT PLC.

California State University, Fullerton Capita PLC Capital One Financial Corporation Card Security LLC CardConnect Carlson Wagonlit Travel Cautela Labs, Inc.CBIZ Security & Advisory Services, LLC CenturyLink Chase Paymentech Citigroup Inc.

Conferma Limited Convergent Network Solutions, Ltd CSC Government Solutions/CSRA LLC Datatrans AG Delaware North Companies, Inc.

Direct Line Insurance Group PLC Dixon Hughes Goodman, LLP Dixons Carphone PLC Elavon Merchant Services Electronic Transactions Association Emirates/Dnata Espion LTD Experis Finance US LLC Fiserv Solutions Inc.

FiveSec Labs Limited, dba Five Security Focal Point Data Risk, LLC Foresight IT Consulting Pty Ltd.

Games Workshop Ltd Global Payments Direct Inc.

Gotham Technology Group, LLC Grant Thornton Habib Bank Limited Harbour IT Pty …

Removed p. 3

• February 2013 1 Executive Summary Cloud computing is a form of distributed computing that is yet to be standardized1. There are a number of factors to be considered when migrating to cloud services, and organizations need to clearly understand their needs before they can determine if and how they will be met by a particular solution or provider. As cloud computing is still an evolving technology, evaluations of risks and benefits may change as the technology becomes more established and its implications become better understood.

The allocation of responsibility between client and provider for managing security controls does not exempt a client from the responsibly of ensuring that their cardholder data is properly secured according to applicable PCI DSS requirements.

It’s important to note that all cloud services are not created equal. Clear policies and procedures should be agreed between client and cloud provider for all security requirements, and responsibilities for …

Removed p. 3

 Executive Summary

• Includes a brief summary of some key points and provides context for the remainder of the document.

 Conclusion

• Presents recommendations for starting discussions about cloud services.

Modified p. 3 → 5

~~This~~ document is structured as follows:

The guidance in this document is structured as follows:

Modified p. 3 → 5

~~ Cloud Overview~~

• Describes the deployment and service models discussed throughout this document.

• Describes the cloud deployment models and service models discussed throughout this document.

Modified p. 3 → 5

 Cloud Provider/ Cloud Customer Relationships

• Discusses how roles and responsibilities may differ across different cloud service and deployment models  PCI DSS Considerations

• Provides guidance and examples to help determine responsibilities for individual PCI DSS requirements, and includes segmentation and scoping considerations.

• Provides guidance and examples to help determine responsibilities for individual PCI DSS requirements, and includes segmentation and scoping considerations.

Modified p. 3 → 5

~~ PCI DSS Compliance Challenges~~

• Describes some of the challenges associated with validating PCI DSS compliance in a cloud environment.

• Describes some of the challenges associated with validating PCI DSS compliance in a cloud environment.

Modified p. 3 → 5

~~ Additional Security Considerations~~

• Explores a number of business and technical security considerations for the use of cloud technologies.

• Explores a number of business and technical security considerations for the use of cloud technologies.

Modified p. 3 → 8

~~Cloud security is a shared responsibility between the cloud service provider (CSP) and its clients.~~ If ~~payment card~~ data is stored, processed or transmitted in a cloud environment, PCI DSS will apply to that environment, and will typically involve validation of both the ~~CSP’s infrastructure~~ and the ~~client’s~~ usage of that environment.

If account data is stored, processed or transmitted in a cloud environment, PCI DSS will apply to that environment, and compliance will typically involve validation of both the Provider’s environment and the Customer’s usage of that environment.

Removed p. 4

This document is intended to provide an initial point of discussion for cloud providers and clients, and does not delve into specific technical configurations. This document does not endorse the use of any specific technologies, products, or services.

 Merchants

• The security and PCI DSS considerations are applicable to all types of cloud environments, and may be useful to merchants managing their own cloud infrastructure as well as those looking to engage with a third party. Guidance for working with third-party cloud providers and PCI DSS compliance challenges may also be useful.

 Cloud service providers

• The security and PCI DSS considerations may provide useful information for CSPs to assist their understanding of the PCI DSS requirements, and may also help CSPs to better understand their clients’ PCI DSS needs. Guidance on CSP/client relationships and PCI DSS compliance challenges may also be useful for providers.

 CSP

• Cloud Service Provider. The CSP, or …

Modified p. 4 → 5

~~• February 2013~~ The following appendices are included to provide additional guidance:

The following appendices are included to provide additional guidance:

Modified p. 4 → 5

~~ Appendix A: PCI DSS Responsibilities for different Service Models~~

• Presents additional considerations to help determine PCI DSS responsibilities across different cloud service models.

• Presents additional considerations to help determine PCI DSS responsibilities across different cloud service models.

Modified p. 4 → 5

~~ Appendix B: Sample Inventory~~

• Presents a sample system inventory for cloud computing environments.

• Presents a sample system inventory for cloud computing environments.

Modified p. 4 → 5

~~ Appendix C: PCI DSS Responsibility Matrix~~

• Presents a sample matrix for documenting how PCI DSS responsibilities are assigned between ~~cloud provider~~ and ~~client.~~

• Presents a sample matrix for documenting how PCI DSS responsibilities are assigned between Provider and Customer.

Modified p. 4 → 5

~~ Appendix D: PCI DSS Implementation Considerations~~

• Suggests a starting set of questions that may help in determining how PCI DSS requirements can be met in a particular cloud environment.

• Suggests a starting set of questions that may help in determining how PCI DSS requirements can be met in a particular cloud environment.

Modified p. 4 → 6

The information in this document ~~is intended as~~ supplemental guidance and does not supersede, replace or extend PCI ~~DSS requirements.~~ For the purposes of this document, all references made ~~are~~ to PCI DSS version ~~2.0.~~

The information in this document provides supplemental guidance and does not supersede, replace or extend the requirements in any PCI SSC standard, nor does it endorse the use of any specific technologies, products or services. For the purposes of this document, all references made to PCI DSS are to version 3.2; however, the general principles and practices offered here may be applied beyond the context of PCI DSS.

Modified p. 4 → 6

~~ Assessors~~

• ~~The~~ security and PCI DSS considerations may help assessors to understand what they ~~might~~ need to know about an environment in order to be able to determine whether a PCI DSS requirement has been met.

• Guidance on the security and PCI DSS considerations that may help assessors to understand what they need to know about an environment in order to be able to determine whether a PCI DSS requirement has been met.

Removed p. 5

• February 2013 2 Cloud Overview Cloud computing provides a model for enabling on-demand network access to a shared pool of computing resources (for example: networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or cloud provider interaction.3 Cloud computing can be used to provide clients with access to the latest technologies without a costly investment in hardware and software. Due to the economies of scale associated with the delivery of cloud services, CSPs can often provide access to a greater range of technologies and security resources than the client might otherwise have access to. Client organizations without a depth of technically-skilled personnel may also wish to leverage the skills and knowledge provided by CSP personnel to securely manage their cloud operations.

 Private cloud

• The cloud infrastructure is operated solely for a single organization (client). It may be managed by the organization …

Removed p. 6

• February 2013 Service models identify different control options for the cloud customer and cloud provider. For example, SaaS customers simply use the applications and services provided by the CSP, where IaaS customers maintain control of their own environment hosted on the CSP’s underlying infrastructure.

The three most commonly used service models are described as follows4:

Software as a Service (SaaS)

• Capability for clients to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser, or a program interface.

It’s important to note that these descriptions for deployment and service models, although widely accepted by the industry, may not be universally followed by cloud providers or reflect actual cloud environments. For example, a CSP might be selling a “private cloud” service that does not meet the intent of “private” as it is described above. Similarly, …

Modified p. 6 → 10

Platform as a Service (PaaS)

• Capability for ~~clients~~ to deploy their applications (created or acquired) onto the cloud infrastructure, using programming languages, libraries, ~~services,~~ and tools supported by the ~~provider.~~

Platform as a Service (PaaS)

• Capability for Customers to deploy their applications (created or acquired) onto the cloud infrastructure, using programming languages, libraries, services and tools supported by the Provider.

Modified p. 6 → 10

Infrastructure as a Service (IaaS)

• Capability for ~~clients~~ to utilize the ~~provider’s~~ processing, storage, ~~networks,~~ and other fundamental computing resources to deploy and run operating systems, applications and other software on a cloud infrastructure.

Infrastructure as a Service (IaaS)

• Capability for Customers to utilize the Provider’s processing, storage, networks and other fundamental computing resources to deploy and run operating systems, applications and other software on a cloud infrastructure.

Modified p. 6 → 10

The main ~~difference~~ between service ~~levels relates~~ to how control is shared between ~~client~~ and ~~CSP,~~ which in turn ~~impacts~~ the level of responsibility for both parties. It should be noted that, other than in a ~~truly~~ private cloud ~~(on-premise)~~ scenario, the ~~client~~ rarely has any control over hardware, and it is the degree to which virtual components, applications and software are managed by the different parties that differentiates the service ~~models.~~ As a general rule, SaaS provides ~~clients~~ with …

The main differences between cloud service categories relate to how control is shared between Customer and Provider, which in turn affects the level of responsibility for both parties. It should be noted that, other than in a self-managed private cloud scenario, the Customer rarely has any control over hardware, and it is the degree to which virtual components, applications and software are managed by the different parties that differentiates the cloud service categories. As a general rule, SaaS provides Customers …

Removed p. 7

Figure 1: Level of control/responsibility for client and CSP across different service models While clients may be attracted to the SaaS and PaaS models due to the resource savings and reduced responsibility for administering the cloud environment, they should be aware that these models also correspond to a greater loss of control of the environment housing their sensitive data. Contractual agreements and ongoing due diligence become especially critical where control is outsourced, to ensure that the required security measures are being met and maintained by the CSP for the duration of the agreement.

 Private cloud

• Where a private cloud is managed on-premise, the CSP role may be undertaken within the client organization. For example, the IT department could take on the role of CSP with various operational departments as its clients. In this scenario, the client organization retains full control of their environment and its security and compliance.

 Public cloud

• …

Modified p. 8 → 12

Dedicated, private clouds may also be provisioned ~~off-premise~~ by a third-party ~~CSP.~~ In this case, the delineation of responsibility will also depend on the particular service ~~model,~~ as described in Section 3.3, “Responsibilities for Different Service Models.”  Community cloud

• The CSP could be one of the client organizations within the community or a separate third party. The delineation of responsibility follows the particular service model implemented.

Dedicated, private clouds may also be provisioned off-premises by a third-party Provider. In this case, the delineation of responsibility will also depend on the particular cloud service category, as described in Section 3.3, “Responsibilities for Different Cloud Service Categories.”

Modified p. 8 → 12

~~ Hybrid cloud~~

• The ~~CSP~~ role may be assigned to both internal and third-party entities for different elements of the overall cloud infrastructure. Responsibility will be assigned based on the combination of deployment models and service ~~models~~ implemented.

• The Provider role may be assigned to both internal and third-party entities for different elements of the overall cloud infrastructure. Responsibility will be assigned based on the combination of deployment models and cloud service categories implemented.

Removed p. 9

• February 2013 3.3 Responsibilities for Different Service Models In all deployment models, and particularly in public cloud environments, it is important for all parties to understand the specific elements of the service model used and its associated risks. Any cloud deployment model that is not truly private (on-premise) is by nature a shared responsibility model, where a portion of responsibility for the cloud service falls under the realm of the CSP, and a portion of responsibility also falls to each client. The level of responsibility that falls to the CSP or the client is determined by the cloud service model being utilized•that is, IaaS, PaaS, or SaaS. Clear delineation of responsibilities should be established as a prerequisite to any cloud service implementation to provide a baseline for the cloud operation.

Figure 2 on the following page illustrates how control of the different technical layers is often shared across different service …

Modified p. 9 → 13

Layer Description Application Program Interface (API) or Graphical User Interface (GUI) The interface ~~used~~ by ~~the client or their customers to~~ interact with the application. The current most common API is RESTful HTTP or HTTPS. The current most common GUI is an ~~HTTP~~ or ~~HTTPS based Web site.~~

Layer Description Application Program Interface (API) or Graphical User Interface (GUI) The interface by which cloud service users interact with the application. The current most common API is RESTful HTTP or HTTPS. The current most common GUI is an HTTP- or HTTPS-based website.

Modified p. 9 → 13

Application The actual application being used by one or more ~~clients~~ or ~~their customers.~~

Application The actual application being used by one or more cloud service users Solution Stack or Technology This is the programming language used to build and deploy applications. Examples are .NET, Python, Ruby, Perl, etc.

Modified p. 9 → 13

~~Operating systems (OS) In a virtualized environment, the OS runs within each VM.~~ Alternatively, if there is no underlying hypervisor present, the operating system runs directly on the storage hardware.

Alternatively, if there is no underlying hypervisor present, the operating system runs directly on the storage hardware.

Modified p. 9 → 13

Virtual ~~network infrastructure~~ For communications within and between virtual machines Hypervisor When virtualization is used to manage resources, the hypervisor is responsible for allocating resources to each virtual machine. It may also be leveraged for implementing security.

Virtual Machine (VM)9 A virtual container executed on a hypervisor on a host. A set of system isolation technologies that provide various degree of security isolation with the host machine’s OS kernel Containers Virtualization technique that allows execution of multiple isolated user- space instances while sharing the same underlying OS kernel Virtual Network Infrastructure For communications within and between virtual machines Hypervisor When virtualization is used to manage resources, the hypervisor is responsible for allocating resources to each virtual machine. …

Modified p. 9 → 14

Network This can be a physical or virtual network. It is responsible for carrying communications between systems and possibly the ~~Internet.~~

Layer Description Processing and Memory The physical hardware that supplies CPU time and physical memory Data Storage The physical hardware used for file storage Network This can be a physical or virtual network. It is responsible for carrying communications between systems and possibly the internet.

Modified p. 9 → 14

Appendix B illustrates a sample inventory for cloud computing ~~systems,~~ as guidance for ~~how CSPs~~ and ~~their customers~~ can document the different layers of the cloud environment.

Physical Facility The actual physical building where the cloud systems are located Appendix B illustrates a sample inventory for cloud computing systems as guidance for the ways in which Providers and Customers can document the different layers of the cloud environment.

Removed p. 10

Figure 2: Example of how control may be assigned between CSP and clients across different service models.

Client CSP Cloud Layer Service Models IaaS PaaS SaaS Interfaces (APIs, GUIs) Applications Solution Stack (Programming languages) Operating Systems (OS) Virtual Machines Virtual network infrastructure Hypervisors Processing and Memory Data Storage (hard drives, removable disks, backups, etc.) Network (interfaces and devices, communications infrastructure) Physical facilities / data centers

Some CSPs offer multiple “options” for their services•for example, a CSP may have one IaaS offering that includes a client-controlled hypervisor and a separate IaaS offering with no client access to the hypervisor. It’s imperative that clients and CSPs clearly document and understand where the boundaries are in their particular relationship rather than assuming that any particular responsibility model applies to them.

Modified p. 10 → 14

Note: This table provides an example of ~~how~~ responsibilities might be assigned according to common descriptions of the different service ~~models.~~ However, ~~it’s~~ important to note that the technology layers and their corresponding lines of responsibility may be different for each ~~CSP,~~ even if they use the same terminology to describe their ~~service,~~ and the individual service offerings may or may not align with the ~~responsibly~~ assignments indicated above.

Note: This table provides an example of the ways in which responsibilities might be assigned according to common descriptions of the different cloud service categories. However, it is important to note that the technology layers and their corresponding lines of responsibility may be different for each Provider, even if they use the same terminology to describe their services, and the individual service offerings may or may not align with the responsibility assignments indicated above.

Removed p. 11

• February 2013 Even where a client does not have control over a particular layer, they may still have some responsibility for the configurations or settings that the CSP maintains on their behalf. For example, a client may need to define firewall rules and review firewall rule-sets for those firewalls applicable to the protection of their environment, even though the CSP actually configures and manages the firewalls. Similarly, clients may be responsible for approving and reviewing user access permissions to their data resources, while the CSP configures the access according to client needs.

Removed p. 11

Identifying all third-party relationships that the CSP has in place is important in order to understand the potential ramifications to a client’s environment. The existence of multiple nested relationships•for example, where there is a chain of vendors and/or other providers required for delivery of a cloud service•will also add complexity to both the CSP’s and the client’s PCI DSS assessment process.

Modified p. 11 → 15

The allocation of responsibility for managing security controls does not exempt a ~~client~~ from the responsibility of ensuring that ~~their~~ cardholder data is properly secured.

The allocation of responsibility for managing security controls does not exempt a Customer from the responsibility of ensuring that its cardholder data is properly secured.

Removed p. 12

 The scope of any additional services the CSP is providing to proactively manage the client’s compliance (for example, additional managed security services).

The client needs to clearly understand the scope of responsibility that the CSP is accepting for each PCI DSS requirement, and which services and system components are validated for each requirement. For example,

 Both

• Generally responsibility is “shared” between the client and the CSP. This may be due to the requirement applying to elements present in both the client environment and the CSP-managed environment, or because both parties need to be involved in the management of a particular control.

Modified p. 12 → 16

Information Supplement

• Supply-chain management Information Supplement

Modified p. 12 → 17

 The purpose for which the ~~client~~ is using the cloud ~~service.~~

• The purpose for which the Customer is using the cloud service

Modified p. 12 → 17

 The scope of PCI DSS requirements that the ~~client~~ is outsourcing to the ~~CSP.~~

• The scope of PCI DSS requirements that the Customer is outsourcing to the Provider

Modified p. 12 → 17

 The services and system components that the ~~CSP~~ has validated within its own ~~operations.~~

• The services and system components that the Provider has validated within its own operations

Modified p. 12 → 17

 The service option that the ~~client~~ has selected to engage the ~~CSP (IaaS,~~ PaaS or ~~SaaS).~~

• The service option that the Customer has selected to engage the Provider (e.g., IaaS, PaaS or SaaS)

Modified p. 12 → 17

PCI DSS Requirements 6.1 and 6.2 address the need for vulnerabilities to be ~~identified,~~ ranked according to risk, and deployed in a timely manner. If not properly defined, a ~~client~~ could assume that the ~~CSP~~ is managing this process for the entire cloud environment, whereas the ~~CSP~~ could be managing vulnerabilities for ~~their~~ underlying infrastructure only, and assuming that the ~~client~~ is managing vulnerabilities for operating systems and applications.

PCI DSS requirement, and which services and system components are validated for each requirement. For example, PCI DSS Requirements 6.1 and 6.2 address the need for vulnerabilities to be identified and ranked according to risk, and for missing patches to be deployed in a timely manner. If not properly defined, a Customer could assume that the Provider is managing this process for the entire cloud environment, whereas the Provider could be managing vulnerabilities for its underlying infrastructure only, and assuming …

Modified p. 12 → 17

~~Figure 3 on the following page~~ provides an example of how responsibilities for PCI DSS requirements may be shared between ~~clients~~ and ~~CSPs~~ across the ~~three~~ service ~~models.~~ There will of course be exceptions and variations across each individual service, and this table is provided as a guideline for ~~clients~~ and ~~CSPs~~ to help plan discussions and negotiations.

Table 2 provides an example of how responsibilities for PCI DSS requirements may be shared between Customers and Providers across some of the various cloud service categories. There will of course be exceptions and variations across each individual service, and this table is provided as a guideline for Customers and Providers to help plan discussions and negotiations.

Modified p. 12 → 17

~~ Client~~

• ~~Generally~~ each ~~client~~ will retain responsibility for maintaining and verifying the requirement.

• Generally, each Customer will retain responsibility for maintaining and verifying the requirement.

Modified p. 12 → 17

~~ CSP~~

• ~~Generally~~ the ~~CSP~~ will maintain and verify the requirement for ~~their clients.~~

• Generally, the Provider will maintain and verify the requirement for its Customers.

Modified p. 12 → 18

Appendix A includes additional considerations for determining how PCI DSS responsibilities may be assigned for each service ~~model.~~

Appendix A includes additional considerations for determining how PCI DSS responsibilities may be assigned for each cloud service category.

Removed p. 13

PCI DSS Requirement Example responsibility assignment for management of controls IaaS PaaS SaaS 1: Install and maintain a firewall configuration to protect cardholder data Both Both CSP 2: Do not use vendor-supplied defaults for system passwords and other security parameters Both Both CSP 3: Protect stored cardholder data Both Both CSP 4: Encrypt transmission of cardholder data across open, public networks Client Both CSP 5: Use and regularly update anti-virus software or programs Client Both CSP 6: Develop and maintain secure systems and applications Both Both Both 7: Restrict access to cardholder data by business need to know Both Both Both 8: Assign a unique ID to each person with computer access Both Both Both 9: Restrict physical access to cardholder data CSP CSP CSP 10: Track and monitor all access to network resources and cardholder data Both Both CSP 11: Regularly test security systems and processes Both Both CSP …

Modified p. 13 → 19

~~Figure 3:~~ Example of ~~how~~ PCI DSS ~~responsibilities may be shared~~ between ~~clients~~ and ~~CSPs.~~

Table 2: Example of PCI DSS responsibility sharing between Customers and Providers

Modified p. 13 → 19

PCI DSS Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers ~~CSP CSP CSP~~

PCI DSS Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers Provider Provider Provider

Modified p. 13 → 19

Note: The sample responsibilities illustrated in this table do not include consideration for any activities or operations performed outside of a hypothetical cloud service offering. This table provides an example of ~~how~~ PCI DSS responsibilities might be assigned for different service ~~models.~~ However, each ~~CSP~~ ultimately defines ~~their~~ own ~~service,~~ and particular service offerings may or may not be consistent with those illustrated above. ~~Clients~~ and ~~CSPs~~ should clearly document their responsibilities as applicable to their particular ~~agreement.~~

Note: The sample responsibilities illustrated in this table do not include consideration for any activities or operations performed outside a hypothetical cloud service offering. This table provides an example of the ways in which PCI DSS responsibilities might be assigned for different cloud service categories. However, each Provider ultimately defines its own service and particular service offerings may or may not be consistent with those illustrated above. Customers and Providers should clearly document their responsibilities as applicable to their particular …

Removed p. 14

• February 2013 Where the CSP maintains responsibility for PCI DSS controls, the client is still responsible for monitoring the CSP’s ongoing compliance for all applicable requirements. CSPs should be able to provide their clients with ongoing assurance that requirements are being met, and where the CSP is managing requirements on behalf of the client, they should have mechanisms in place to provide the customer with the applicable records•for example, audit logs showing all access to client data.

Removed p. 14

In addition to enforcing separation between client environments, segmentation may also be desired within a client’s environment to isolate their CDE components from non-CDE components in order to reduce their own

Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system, and application layers; and most importantly, there should be guaranteed isolation of data that is stored. Client environments must be isolated from each other such that they can be considered separately managed entities with no connectivity between them. Any systems or components shared by the client environments, including the hypervisor and underlying systems, must not provide an access path between environments. Any shared infrastructure used to house an in-scope client environment would be in scope for that client’s PCI DSS assessment.

A segmented cloud environment exists when the CSP …

Modified p. 14 → 18

~~Clients~~ are still required to validate their compliance in accordance with payment brand programs.

Customers are still required to validate their compliance in accordance with payment brand programs.

Modified p. 14 → 18

Appendix C illustrates a sample PCI DSS ~~Responsibly~~ Matrix, as guidance for how ~~CSPs~~ and ~~their customers~~ can document PCI DSS responsibility assignments.

Appendix C illustrates a sample PCI DSS Responsibility Matrix, as guidance for how Providers and Customers can document PCI DSS responsibility assignments.

Removed p. 15

• February 2013  Environments where clients run their applications in separate logical partitions using separate database management system images and do not share disk storage or other resources.

The PCI DSS assessor must validate the effectiveness of the segmentation to ensure it provides adequate isolation. If adequate segmentation is provided between clients, the client environment and the CSP-managed environment and processes would be in scope for a client’s PCI DSS assessment. If adequate segmentation is not in place or cannot be verified, the entire cloud environment would be in-scope for any one client’s assessment. Examples of “non-segmented” cloud environments include but are not limited to:

 Environments where organizations use the same application image on the same server and are only separated by the access control system of the operating system or the application.

 Environments where organizations use different images of an application on the same server and are only separated …

Removed p. 15

In a private cloud environment, one approach that may help reduce the complexity of segmentation efforts could be to locate all CDE virtual components on a dedicated “CDE hypervisor,” and ensure all non-CDE virtual components are located on separate hypervisors, adequately segmented from the CDE hypervisor.

The need for adequate segmentation of client environments in a public or shared cloud is underscored by the principle that the other client environments running on the same infrastructure are to be considered untrusted networks. The client has no way of confirming whether other client environments are securely configured, patched appropriately to protect against attack, or that they are not already compromised or even designed to be malicious. This is particularly relevant where a CSP offers IaaS and PaaS services, as the individual clients have greater control and management of their environments.

Removed p. 16

• February 2013 4.4.2 Segmentation Responsibilities Ultimately, the CSP needs to take ownership of the segmentation between clients and verify it is effective and provides adequate isolation between individual client environments, between client environments and the CSP’s own environment, and between client environments and other untrusted environments (such as the Internet). Applicable PCI DSS controls for the segmentation functions would also be the CSP’s responsibility (for example, firewall rules, audit logging, documentation, reviews, etc.). The client is responsible for the proper configuration of any segmentation controls implemented within their own environment (for example, using virtual firewalls to separate in-scope VMs from out-of-scope VMs), and for ensuring that effective isolation is maintained between in-scope and out-of-scope components.

Clients wishing to implement segmentation within their cloud environment also need to consider how the CSP’s environment and processes may impact the effectiveness of the segmentation. For example, CSP systems could be providing connectivity between …

Removed p. 16

This would require hypervisors with multiple network interfaces and PCI DSS compliant configurations for the various types of network hardware. Additionally, virtual counterparts of firewalls, switches and routers now exist and can be incorporated into a virtual environment.

As mentioned above, a key consideration is how secure the “common layers” (such as hypervisors and shared physical components) are, and whether they represent a potential attack surface between zones or clients. The answer is that yes, they do; however the associated risks are still not well understood.

Removed p. 17

• February 2013 4.5 Scoping Considerations Merchant or other organizations looking to store, process, or transmit payment card data in a cloud environment should clearly understand the impact that extending their CDE into the cloud will have on their

PCI DSS scope. For example, in a private-cloud deployment, an organization could either implement adequate segmentation to isolate in-scope systems from other systems and services, or they could consider their private cloud to be wholly in scope for PCI DSS. In a public cloud, the client organization and CSP will need to work closely together to define and verify scope boundaries, as both parties will have systems and services in scope.

Appendix D includes Implementation Considerations for PCI DSS Requirements.

PCI DSS requirements applicable to the cloud environment. As an example, let’s say the client performs all encryption and decryption operations and all key-management functions5 in their own data center and uses a third-party …

Modified p. 17 → 24

~~ Don’t~~ store, process or transmit payment card data in the cloud. This is the most effective way to ~~keep~~ a cloud ~~environment out of scope, as PCI DSS controls are not required if there is no payment card data to protect.~~

• Do not store, process or transmit payment card data in the cloud. This is the most effective way to reduce the scope of PCI DSS in a cloud environment.

Modified p. 17 → 24

 Implement a dedicated physical infrastructure that is used only for the in-scope cloud environment. The scoping process will be simplified if all in-scope operations are limited to a known, defined set of physical and virtual system components that are managed independently from other components. Once defined, the ~~client~~ will be reliant on the ~~CSP’s~~ ability to ensure scope boundaries are ~~maintained•for~~ example, by ensuring that all segmentation controls are operating effectively and that any new components connected to the …

• Implement a dedicated physical infrastructure that is used only for the in-scope cloud environment. The scoping process will be simplified if all in-scope operations are limited to a known, defined set of physical and virtual system components that are managed independently from other components. Once these are defined, the Customer will be reliant on the Provider’s ability to ensure that scope boundaries are maintainedfor example, by ensuring that all segmentation controls are operating effectively and that any new components …

Modified p. 17 → 24

 Minimize reliance on third-party ~~CSPs~~ for protecting payment card data. The more security controls the ~~CSP~~ is ~~responsible for,~~ the greater the scope of the CDE will potentially be, thereby increasing the complexity involved in defining and maintaining CDE boundaries.

• Minimize reliance on third-party Providers for protecting payment card data. The more security controls for which the Provider is responsible, the greater the scope of the CDE will potentially be, thereby increasing the complexity involved in defining and maintaining CDE boundaries.

Modified p. 17 → 24

Ensuring that clear-text account data is never accessible in the cloud may also ~~assist~~ to reduce the number of

Ensuring that clear-text account data is never accessible in the cloud may also help to reduce the number of

Modified p. 17 → 25

It should be noted that the encrypted data is still in scope for PCI DSS (generally for the entity that controls or manages the encrypted data ~~and/or~~ the cryptographic ~~keys6)~~ to ensure that applicable controls are in place.

It should be noted that the encrypted data is still in scope for PCI DSS (generally for the entity that controls or manages the encrypted data or the cryptographic keys13) to ensure that applicable controls are in place.

Modified p. 17 → 25

However, by keeping all encryption/decryption and key-management operations isolated from the cloud, the number of PCI DSS requirements that the ~~CSP~~ is required to maintain may be reduced, as these requirements will instead be applicable to the ~~client’s~~ own environment and personnel. The ~~CSP~~ will still be in scope for any PCI DSS requirements it manages on behalf of the ~~client•for~~ example, access controls managed by the ~~CSP~~ will need to be verified to ensure that only authorized persons (as …

However, by keeping all encryption/decryption and key-management operations isolated from the cloud, the number of PCI DSS requirements that the Provider is required to maintain may be reduced, as these requirements will instead be applicable to the Customer’s own environment and personnel. The Provider will still be in scope for any PCI DSS requirements it manages on behalf of the Customerfor example, access controls managed by the Provider will need to be verified to ensure that only authorized persons (as …

Removed p. 18

 All VMs are hosted on one or more hypervisors; some VMs are considered part of the CDE and some are not.

Modified p. 18 → 25

~~• February 2013~~ Alternatively, if clear-text account data is present (for example, in memory) in the cloud environment, or the ability to retrieve account data exists (for example, if decryption keys and encrypted data are present), all applicable PCI DSS requirements would apply to that environment.

Alternatively, if clear-text account data is present (for example, in memory) in the cloud environment, or the ability to retrieve account data exists (for example, if decryption keys and encrypted data are present), all applicable PCI DSS requirements would apply to that environment.

Modified p. 18 → 26

Scenario Environment ~~description~~ PCI DSS ~~scoping guidance~~ Case 1: Private ~~Cloud~~ hosted and controlled by entity seeking PCI DSS compliance, with ~~segmentation.~~

Scenario Environment Description PCI DSS Scoping Guidance Case 1: Private cloud hosted and controlled by entity seeking PCI DSS compliance, with segmentation

Modified p. 18 → 26

 All CDE VMs are hosted on a single, dedicated ~~hypervisor;~~ non-CDE VMs are hosted on a separate ~~hypervisor(s).~~

• All CDE VMs or containers are hosted on a single, dedicated hypervisor/server; non-CDE VMs are hosted on a separate hypervisor(s) or server(s).

Modified p. 18 → 26

 Validated segmentation of CDE systems from non-CDE systems using a combination of physical and logical ~~controls~~ The CDE ~~hypervisor~~ and ~~VMs,~~ and all ~~cloud~~ components that are not segmented are in scope (segmentation must be validated as providing effective ~~isolation) Case 2: Private Cloud hosted and controlled by entity seeking PCI DSS compliance, no segmentation.~~

• Validated segmentation of CDE systems from non-CDE systems using a combination of physical and logical controls.15 The CDE hypervisor, VMs and containers, and all system components that are not segmented are in scope (segmentation must be validated as providing effective isolation).

Modified p. 18 → 26

 No segmentation of CDE systems from non-CDE systems.

• No segmentation of CDE systems from non-CDE systems.

Removed p. 19

 Validated segmentation of client environments using a combination of physical and logical controls.

The CSP is responsible for compliance of all elements of the cloud service provided. Each client’s scope would include their own environment (for example, VMs, applications etc.) and any other elements not managed by the CSP. Segmentation must be validated as providing effective isolation between clients as part of the CSP’s validation, and may require additional validation as part of each client’s validation.

Entire cloud service and all client environments are in scope. Note that validating PCI DSS compliance may be intractable and infeasible as every client environment would need to be included in the assessment.

Modified p. 19 → 27

~~• February 2013~~ Scenario Environment ~~description~~ PCI DSS ~~scoping guidance~~ Case 3: Third-party ~~CSP~~ hosting a ~~“PCI~~ DSS ~~compliant”~~ public cloud supporting multiple ~~clients,~~ with validated segmentation for ~~client environments.~~

Scenario Environment Description PCI DSS Scoping Guidance Case 3: Third-party Provider hosting a PCI DSS compliant public cloud supporting multiple Customers, with validated segmentation for Customer environments

Modified p. 19 → 27

 VMs may be on one or multiple ~~hypervisors,~~ all hypervisors and VMs are configured by ~~CSP~~ to support PCI DSS requirements.

• VMs may be on one or multiple hypervisors; all hypervisors and VMs are configured by Provider to support PCI DSS requirements.

Modified p. 19 → 27

 Multiple ~~clients~~ hosted on each hypervisor.

• Multiple Customers are hosted on each hypervisor.

Modified p. 19 → 27

Case 4: Third-party ~~CSP~~ hosting a ~~“PCI~~ DSS ~~compliant”~~ public cloud supporting multiple ~~clients,~~ no ~~client segmentation.~~

Case 4: Third-party Provider hosting a PCI DSS compliant public cloud supporting multiple Customers, no Customer segmentation

Modified p. 19 → 27

 VMs may be on one or multiple ~~hypervisors,~~ all hypervisors configured by ~~CSP~~ to support

• VMs may be on one or multiple hypervisors; all hypervisors configured by Provider to support PCI DSS requirements.

Modified p. 19 → 27

 Multiple ~~clients~~ hosted on each hypervisor, VM configuration managed by each ~~client.~~

• Multiple Customers are hosted on each hypervisor, VM configuration managed by each Customer.

Modified p. 19 → 27

 Segmentation between ~~client~~ environments is not verified.

• Segmentation between Customer environments is not verified. All systems are in scope.

Removed p. 20

• February 2013 5 PCI DSS Compliance Challenges Storing, processing, or transmitting cardholder data in the cloud brings that cloud environment into scope for

PCI DSS, and it may be particularly challenging to validate PCI DSS compliance in a distributed, dynamic infrastructure such as a public or other shared cloud. For example, it can be difficult to identify which system components are in scope for a particular service, or identify who is responsible for particular PCI DSS controls. Some of the technical controls and auditing processes traditionally used to attain a measurable level of assurance in static environments (for example, in-house data storage servers) are not designed for rapidly- changing cloud environments and processes (for example, cloud bursting, continual deployment and retirement of virtual machines, dynamic IP addressing, and so on). Additionally, clients and assessors often can’t “see and touch” CDE systems as they would in a traditional environment (for example, …

Modified p. 20 → 30

~~ Clients~~ may have limited or no oversight or control over cardholder data storage. Organizations might not know where cardholder data is physically stored, or the location(s) can regularly change. For redundancy or ~~high availability~~ reasons, data could be stored in multiple locations at any given time.

• Customers may have limited or no oversight or control over cardholder data storage. Organizations might not know where cardholder data is physically stored, or the location(s) can regularly change. For redundancy or high-availability reasons, data could be stored in multiple locations at any given time.

Modified p. 20 → 30

 Some virtual components do not have the same ~~level~~ of access control, ~~logging,~~ and monitoring as their physical counterparts.

• Some virtual components do not have the same levels of access control, logging and monitoring as their physical counterparts.

Modified p. 20 → 30

 Perimeter boundaries between ~~client~~ environments can be fluid.

• Perimeter boundaries between Customer environments can be fluid.

Modified p. 20 → 30

 Public cloud environments are usually designed to allow access from anywhere on the ~~Internet.~~

• Public cloud environments are usually designed to allow access from anywhere on the internet.

Modified p. 20 → 30

 It can be challenging to verify who has access to cardholder data processed, ~~transmitted,~~ or stored in the cloud environment.

• It can be challenging to verify who has access to cardholder data processed, transmitted or stored in the cloud environment.

Modified p. 20 → 30

 It can be challenging to collect, ~~correlate, and/or~~ archive all of the logs necessary to meet applicable PCI DSS requirements.

• It can be challenging to collect, correlate and archive all the logs necessary to meet applicable PCI DSS requirements.

Modified p. 20 → 30

 Organizations using data-discovery tools to identify cardholder data in their environments, and to ensure that such data is not stored in unexpected places, may find that running such tools in a cloud environment can be difficult and result in incomplete results. It can be challenging for organizations to verify that cardholder card data has not ~~“leaked”~~ into the cloud.

• Organizations using data-discovery tools to identify cardholder data in their environments, and to ensure that such data is not stored in unexpected places, may find that running such tools in a cloud environment can be difficult and result in incomplete results. It can be challenging for organizations to verify that cardholder card data has not "leaked" into the cloud.

Removed p. 21

At a high level, CSPs can be identified as those that have been validated as meeting a particular level of PCI DSS compliance and those that have not. The recommended practice for clients with PCI DSS considerations is to work with CSPs whose services have been independently validated as being PCI DSS compliant.

Removed p. 21

Much stock is placed in the statement “I am PCI compliant”, but what does this actually mean for the different parties involved? Use of a PCI DSS compliant CSP does not result in PCI DSS compliance for the clients. The client must still ensure they are using the service in a compliant manner, and is also ultimately responsible for the security of their CHD•outsourcing daily management of a subset of PCI DSS requirements does not remove the client’s responsibility to ensure CHD is properly secured and that PCI DSS controls are met. The client therefore must work with the CSP to ensure that evidence is provided to verify that PCI DSS controls are maintained on an ongoing basis•an Attestation of Compliance (AOC) reflects a single point in time only; compliance requires ongoing monitoring and validation that controls are in place and working effectively.

Modified p. 21 → 30

~~• February 2013~~ These challenges will ~~impact~~ a number of factors related to how PCI DSS compliance is managed, including how segmentation is implemented, how PCI DSS assessments are scoped, how individual PCI DSS requirements are ~~validated,~~ and which party will perform particular validation activities.

These challenges will affect a number of factors related to how PCI DSS compliance is managed, including how segmentation is implemented, how PCI DSS assessments are scoped, how individual PCI DSS requirements are validated and which party will perform particular validation activities.

Modified p. 21 → 31

Even where a cloud service is validated for certain PCI DSS requirements, this validation does not automatically transfer to the ~~client~~ environments within that cloud service. For example, a ~~CSP’s~~ validation may have included use of up-to-date anti-virus software on the ~~CSP’s~~ systems; however, this validation might not extend to the individual ~~client~~ OS or VMs (such as in an IaaS service). Additionally, the ~~client~~ must still maintain compliance for all of ~~their~~ own ~~operations•for~~ example, by ensuring ~~anti-virus~~ is …

Even where a cloud service is validated for certain PCI DSS requirements, this validation does not automatically transfer to the Customer environments within that cloud service. For example, a Provider’s validation may have included use of up-to-date anti-virus software on the Provider’s systems; however, this validation might not extend to the individual Customer OS or VMs (such as in an IaaS service). Additionally, the Customer must still maintain compliance for all of its own operationsfor example, by ensuring that anti- …

Modified p. 21 → 31

Similarly, a ~~client’s~~ PCI DSS compliance does not result in any claim of compliance for the ~~CSP,~~ even if the ~~client’s~~ validation included elements of the service managed by the ~~CSP.~~

Similarly, a Customer’s PCI DSS compliance does not result in any claim of compliance for the Provider, even if the Customer’s validation included elements of the service managed by the Provider. As a result, a Customer should confirm that services provided by the Provider support its PCI DSS compliance.

Modified p. 21 → 31

Regarding the applicability of one party’s compliance to the other, consider the following:

Regarding the applicability of one party’s PCI DSS compliance to the other, consider the following:

Modified p. 21 → 31

a) If a ~~CSP~~ is compliant, this does not mean that ~~their clients~~ are.

• If a Provider is compliant, this does not mean that its Customers are.

Modified p. 21 → 31

b) If a ~~CSP’s clients~~ are compliant, this does not mean that ~~the CSP is.~~

• If a Provider and the Customer are compliant, this does not mean that any other Customers are.

Modified p. 21 → 31

c) If a ~~CSP and the client are~~ compliant, this does not mean that ~~any other clients are.~~

• If one or more of a Provider’s Customers is compliant, this does not mean that the Provider is compliant.

Modified p. 21 → 31

The ~~CSP~~ should ensure that any service offered as being ~~“PCI compliant”~~ is accompanied by a clear and unambiguous explanation, supported by appropriate evidence, of which aspects of the service have been validated as compliant and which have not.

The Provider should ensure that any service offered as being PCI DSS compliant is accompanied by a clear and unambiguous explanation, supported by appropriate evidence, detailing which aspects of the service have been validated as compliant and which have not.

Removed p. 22

• February 2013 Considerations for the client may include:

 How does the CSP ensure that clients using the PCI DSS compliant service cannot introduce non- compliant components to the environment or bypass any PCI DSS controls? CSPs should provide their clients with evidence that clearly identifies what was included in the scope of their PCI DSS assessment, as well as the specific PCI DSS requirements that the environment was assessed against, and the date of the assessment. All aspects of the cloud service not covered by the CSP’s PCI DSS assessment should also be identified and documented, as these will need to be validated either by the client or the CSP in order for a client’s assessment to be completed. The client must have a detailed understanding of any security requirements that are not covered by the provider and are therefore the client’s responsibility to implement, manage, and validate as …

Modified p. 22 → 32

 How long has the ~~CSP~~ been PCI DSS compliant? When was ~~their~~ last validation?

• How long has the Provider been PCI DSS compliant? When was its last validation?

Modified p. 22 → 32

 What specific services ~~and PCI DSS requirements~~ were included in the validation?

• What specific services were included in the validation?

Modified p. 22 → 32

 What specific facilities and system components were included in the validation?

• What specific services, facilities and system components were included in the validation?

Modified p. 22 → 32

 Are there any system components that the ~~CSP~~ relies on for delivery of the service that were not included in the PCI DSS validation?

• Are there any system components that the Provider relies on for delivery of the service that were not included in the PCI DSS validation?

Modified p. 22 → 33

~~CSPs~~ that have undergone PCI DSS compliance assessment and validation should be able to provide their ~~clients~~ with the following:

Providers that have undergone PCI DSS compliance assessment and validation should be able to provide their Customers with the following:

Removed p. 23

• February 2013 CSPs that have not undergone a PCI DSS compliance assessment will need to be included in their client’s assessment. The CSP will need to agree to provide the client’s assessor with access to their environment in order for the client to complete their assessment. The client’s assessor may require onsite access and detailed information from the CSP, including but not limited to:

 Evidence (such as configurations, screen shots, process reviews, etc.) to show that all applicable PCI DSS requirements are being met for the in-scope system components  Appropriate contract language, if applicable The client and CSP will need to agree upon which assessment activities can be performed by the client and which testing is the responsibility of the CSP. For example, in an IaaS/PaaS service, the client may wish to test within their own environment and whatever else they can access, such as the boundaries between …

Modified p. 23 → 33

 Access to systems, ~~facilities,~~ and appropriate personnel for ~~on-site~~ reviews, interviews, physical walk- throughs, etc.

• Access to systems, facilities and appropriate personnel for onsite reviews, interviews, physical walk- throughs, etc.

Modified p. 23 → 33

 Policies and procedures, process documentation, configuration standards, training records, incident response plans, etc.

• Policies and procedures, process documentation, configuration standards, training records, incident response plans, etc.

Modified p. 23 → 34

~~CSPs~~ wishing to provide a PCI DSS compliant service may ~~wish~~ to consider isolating the PCI DSS compliant services from their non-PCI compliant services. This may help to simplify the compliance validation process for both the ~~CSP~~ and for ~~their~~ individual ~~clients.~~ It may also help the ~~CSP~~ to standardize the PCI DSS compliant services being provided to ~~their clients.~~

Providers wishing to provide a PCI DSS compliant service may want to consider isolating the PCI DSS compliant services from their non-PCI DSS compliant services. This may help to simplify the compliance validation process for both the Provider and for its individual Customers. It may also help the Provider to standardize the PCI DSS compliant services being provided to its Customers.

Modified p. 24 → 35

~~In traditional environments, the physical location of sensitive data can be restricted to dedicated systems, facilitating the identification and implementation of effective risk-mitigation controls.~~ However, the advent of new technologies requires a reevaluation of traditional risk strategies. For example, data in cloud environments is no longer tied to a physical system or location, reducing the effectiveness of traditional security mechanisms to protect data from risk. Traditional security approaches that build security controls ~~“around”~~ sensitive data may therefore need to evolve …

However, the advent of new technologies requires a reevaluation of traditional risk strategies. For example, data in cloud environments is no longer tied to a physical system or location, reducing the effectiveness of traditional security mechanisms to protect data from risk. Traditional security approaches that build security controls to protect sensitive data may therefore need to evolve to address this emerging risk environment.

Modified p. 24 → 36

Similarly, traditional forms of risk assessment might not take into consideration particular cloud characteristics, such as a ~~pay-as-you go~~ model or multi-tenancy (described in Section ~~6.5.7),~~ and may therefore require new or modified procedures.

Similarly, traditional forms of risk assessment might not take into consideration particular cloud characteristics, such as a pay-as-you-go model or multi-tenancy (described in Section E2, “Multi- tenancy”), and may therefore require new or modified procedures.

Removed p. 25

• February 2013 to engagement of the CSP. The specific due-diligence process and goals will vary for each client organization, however common objectives typically include:

The scope of the due-diligence exercise should consider, at a minimum, the topics discussed throughout this document, as applicable to a client’s particular requirements.

Modified p. 25 → 36

1. Confirming the ~~provider~~ has a history of sound work practices and ethical behavior and is legitimately performing the services the ~~client~~ believes ~~them~~ to be

• Confirming that the Provider has a history of sound work practices and ethical behavior and is legitimately performing the services the Customer believes it to be

Modified p. 25 → 36

2. Verifying that the ~~provider~~ is compatible with the ~~client’s~~ business image and risk profile

• Verifying that the Provider is compatible with the Customer’s business image and risk profile

Modified p. 25 → 36

3. Identifying potential risks or circumstances associated with the ~~provider~~ that may ~~impact~~ the ~~client’s~~ operations or business

• Identifying potential risks or circumstances associated with the Provider that may affect the Customer’s operations or business

Modified p. 25 → 36

4. Identifying elements of the service that need to be clarified, and that need to be included in contracts ~~or service agreements Due~~ diligence is not simply reading the ~~provider’s~~ marketing material or relying on a ~~provider’s~~ claims of ~~“PCI compliance” or secure operations. Clients~~ should be sufficiently assured that they are engaging with a ~~provider~~ that can meet their security and operational needs before undertaking any such engagements.

• Identifying elements of the service that need to be clarified, and that need to be included in contracts Effective due diligence is not simply reading the Provider’s marketing material or relying on a Provider’s claims of PCI compliance; rather, it involves research, review and evidence collection. Customers should be sufficiently assured that they are engaging with a Provider that can meet their security and operational needs before undertaking any such engagements. The scope of the due-diligence exercise should consider, …

Modified p. 25 → 36

Typically, ~~cloud-hosting~~ agreements are concerned with ~~“up-time”~~ and high availability, with little or no mention or assurance of security. However, the ~~client~~ is ultimately responsible for ensuring the service ~~they’re~~ using meets ~~their~~ security requirements and compliance obligations.

Typically, cloud hosting agreements are concerned with "up time" and high availability, with little or no mention or assurance of data integrity and security. However, the Customer is ultimately responsible for ensuring that the service that it is using meets its data integrity and security requirements and compliance obligations.

Modified p. 25 → 37

SLAs and other written agreements between the ~~CSP~~ and ~~client~~ should clearly identify the delineation of responsibilities between parties, including responsibilities for implementing and managing different security controls. These SLAs and ~~agreements~~ should be established as a prerequisite to any cloud service implementation. PCI DSS compliance validation and testing activities (with the associated controls, ~~permissions,~~ and schedules) should also be clearly detailed in the SLA.

SLAs and other written agreements between the Provider and Customer should clearly identify the delineation of responsibilities between parties, including responsibilities for implementing and managing different security controls. These SLAs form the fundamental components of the manner in which operations and security will be undertaken and as a result should be established as a prerequisite to any cloud service implementation. PCI DSS compliance validation and testing activities (with the associated controls, permissions and schedules) should also be clearly detailed in …

Modified p. 25 → 37

Failure to develop and agree upon appropriate SLAs may result in issues for the ~~client~~ if the cloud service does not meet the needs and demands of ~~their~~ business. SLAs should be established and agreed as part of any contract and service negotiations. Performance, availability, ~~integrity,~~ and confidentiality should be considered and SLAs agreed for each service managed ~~and/or~~ operated by the ~~CSP.~~ Written agreements should also cover activities and assurances to be provided by both parties upon termination of …

Failure to develop and agree upon appropriate SLAs may result in issues for the Customer if the cloud service does not meet the needs and demands of its business. SLAs should be established and agreed upon as part of any contract and service negotiations. Performance, availability, integrity and confidentiality should be considered and SLAs agreed upon for each service managed or operated by the Provider. Written agreements should also cover activities and assurances to be provided by both parties upon …

Removed p. 26

• February 2013 that might be used to store, process, or transmit cardholder data in BCP or DR situation, The ability to perform tests of the BCP and DR capabilities and/or to observe results of the CSP’s testing should also be considered.

Removed p. 26

Other legal considerations include requirements for electronic discovery, evidence preservation and integrity, and data custody. CSPs should have documented processes for responding to legal requests for seizure of records, including data/audit logs belonging to the CSP and their clients. Clients should understand the ramifications of such laws in the countries where their data exists, as well as the processes that their CSP will engage in.

Modified p. 26 → 37

In a private cloud, the physical location of all components is known and can be verified. When using a public cloud, different elements of the environment, such as VMs, hypervisors, virtual network devices, etc., could be frequently relocated according to the CSP’s load-balancing strategy. Verifying that appropriate physical security is in place can be challenging in an environment where data and infrastructure can be in multiple different locations at different times. A client should seek assurance that their physical security …

In a private cloud, the physical location of all components is known and can be verified. When using a public cloud, different elements of the environment, such as VMs, hypervisors, virtual network devices, etc., could be Information Supplement

Modified p. 26 → 39

Understanding the legal jurisdictions that apply to data in different countries or regions can be a challenge for the ~~client organization.~~ For example, ~~clients~~ subject to regional laws restricting cross-border flows of data will need to verify all locations and flows of their data to ensure their cloud ~~service is~~ compliant with their legal obligations.

Understanding the legal jurisdictions that apply to data in different countries or regions can be a challenge for the Customer. For example, Customers subject to regional laws restricting cross-border flows of data will need to verify all locations and flows of their data to ensure that their cloud services are compliant with their legal obligations.

Removed p. 27

• February 2013 6.4 Data Security Considerations Further to the data-sovereignty considerations mentioned above, public-cloud providers often have multiple data storage systems located in multiple data centers, which may often be in multiple countries or regions.

Modified p. 27 → 39

Consequently, the ~~client~~ may not know the location of ~~their~~ data, or the data may exist in one or more of several locations at any particular time. Additionally, a ~~client~~ may have little or no visibility into the controls protecting ~~their~~ stored data. This can make validation of data security and access controls for a specific data set particularly challenging.

Further to the data sovereignty considerations mentioned above, public Providers often have multiple data storage systems located in multiple data centers, which may often be in multiple countries or regions. Consequently, the Customer may not know the location of its data, or the data may exist in one or more of several locations at any particular time. Additionally, a Customer may have little or no visibility into the controls protecting its stored data. This can make validation of data security …

Modified p. 27 → 40

Potential hypervisor access to data in memory should also be taken into consideration, to ensure that ~~client-defined~~ access controls are not unintentionally bypassed by ~~CSP~~ administrator personnel.

Potential hypervisor access to data in memory should also be taken into consideration, to ensure that Customer-defined access controls are not unintentionally bypassed by Provider administrator personnel.

Removed p. 28

• February 2013  Accessible only to those with a business need, and  Handled in accordance with the client’s security policy (See PCI DSS Requirements 3, 7, and 10.7) Because all environments outside the client-controlled environment could potentially be untrusted, cloud services should support the secure transmission of cardholder data throughout the cloud infrastructure, between the client and cloud environments, between client environments, and between the cloud infrastructure and other public networks. It is recommended that sensitive data be encrypted for all transmissions through any cloud environment that is not entirely private and/or controlled by the client.

Cloud environments outside of the client-controlled environment should be treated as “open” or “public” networks (see PCI DSS Requirement 4.1).

Removed p. 28

Because compromise of a CSP could result in unauthorized access to multiple data stores, it is recommended that cryptographic keys used to encrypt/decrypt sensitive data be stored and managed independently from the cloud service where the data is located. At a minimum, key-management servers should be located in a separate network segment and protected with separate access credentials from the VMs that are using the keys and the data encrypted with them.

Modified p. 28 → 40

Organizations should ensure that their particular data security needs can be met by the cloud service before migrating that data into the cloud environment. Considerations should include how storing data types with different levels of sensitivity in the same virtual environment may ~~impact~~ the protection levels required for each data type. Cardholder data, user credentials and passwords, and cryptographic keys are examples of sensitive data that must be protected according to ~~their~~ individual needs.

Organizations should ensure that their particular data security needs can be met by the cloud service before migrating that data into the cloud environment. Considerations should include how storing data types with different levels of sensitivity in the same virtual environment may affect the protection levels required for each data type. Cardholder data, user credentials and passwords, and cryptographic keys are examples of sensitive data that must be protected according to its individual needs.

Removed p. 29

• February 2013 Only defined, authorized key custodians should have access to cryptographic keys. Because access to both keys and encrypted data provides the ability to decrypt the data, clients will need to verify who has access to cryptographic keys, who has access to the encrypted data, and who has access to both. If a client shares encryption keys with the CSP, or engages the CSP as a key custodian, details of CSP access permissions and processes will also need to be reviewed and verified.

This consideration is particularly critical if cryptographic keys are stored or hosted by a third-party CSP that also hosts the encrypted data. If CSP personnel have access to a client’s keys and the client’s encrypted data, the client may have unintentionally granted the CSP ability to decrypt their sensitive data.

Any data that is decrypted in the cloud may be inadvertently captured in clear text in process …

Removed p. 30

• February 2013 SSC website•that discuss security considerations for the use of virtual technologies. Some of these considerations include:

The use of a single client credential that covers multiple cloud services for that client is also a potential concern. For example, let’s say a CSP issues a client with a user account and password that has administrator privilege in one environment and user-level privilege for a separate, unrelated cloud service.

Compromise of the client’s user-level account in the second environment could therefore result in the attacker gaining administrator-level access to the first environment. Client accounts and passwords should be unique for each service, and any account with elevated privilege (such as administrator) should be restricted for a specific service or function, and not used for activities or access that do not require such privilege.

Modified p. 30 → 64

 It is difficult to maintain up-to-date, secure configurations on virtual machines when they are being activated and deactivated in rapid cycles

•virtual machines that are dormant for any period of time may be improperly secured or introduce security vulnerabilities when activated.

• It is difficult to maintain up-to-date, secure configurations on virtual machines when they are being activated and deactivated in rapid cyclesvirtual machines that are dormant for any period of time may be improperly secured or may introduce security vulnerabilities when activated.

Modified p. 30 → 64

 Security and monitoring solutions for virtual networks are still evolving and are not as mature as those available for physical networks.

• Security and monitoring solutions for virtual networks are still evolving and are not as mature as those available for physical networks; for instance, continuous segmentation testing between the cloud tenants’ networks.

Modified p. 30 → 64

 Management of VM-to-VM traffic that does not pass through traditional network-based security controls may require the use of additional host-based security controls to monitor and control the traffic.

• Management of VM-to-VM traffic that does not pass through traditional network-based security controls may require the use of additional host-based security controls to monitor and control the traffic.

Modified p. 30 → 64

 Traditional agent-based software security solutions that are not designed for virtualized environments may cause operational issues. For example, software agents, such as those often used for ~~anti-virus,~~ each use a small percentage of memory and processing resources; this can result in a large overhead when multiple agents are installed on multiple VMs on the same host.

• Traditional agent-based software security solutions that are not designed for virtualized environments may cause operational issues. For example, software agents, such as those often used for anti-virus protection, each use a small percentage of memory and processing resources; this can result in a large overhead when multiple agents are installed on multiple VMs on the same host.

Modified p. 30 → 64

 Scheduled scans or updates occurring simultaneously across multiple VMs may result in an extreme load on the underlying system and reduce overall performance of all hosted VMs.

• Scheduled scans or updates occurring simultaneously across multiple VMs may result in an extreme load on the underlying system and reduce overall performance of all hosted VMs.

Removed p. 31

• February 2013 applications. In this scenario, the ability to associate various log files into meaningful events would require correlation of client-controlled logs and those controlled by the CSP.

Hypervisor configuration and access is particularly important as it provides a single point of entry to all its VMs, and can potentially be used to gain access to sensitive data and resources on separate VMs.

Functionality that allows the hypervisor to control and monitor individual VM activity from outside the VMs is known as introspection9. Hypervisor introspection expands the functionality of the hypervisor to allow a deeper analysis of the data being processed by the VM, and typically includes visibility into stored data files as well as monitoring of network traffic, memory and program execution, and other elements of the VM.

Additionally, since introspection is designed to have full visibility into each VM, it may be difficult to restrict such access to only specific …

Modified p. 31 → 68

An additional consideration is the degree to which the hypervisor is used to deliver security functionality to the VMs. For example, a simple, hardened hypervisor may be very secure but offer limited security capabilities, whereas a more complex, security-capable hypervisor with improved functionality could potentially present a greater risk if ~~compromised8.~~

An additional consideration is the degree to which the hypervisor is used to deliver security functionality to the VMs. For example, a simple, hardened hypervisor may be very secure but offer limited security capabilities, whereas a more complex, security-capable hypervisor with improved functionality could potentially present a greater risk if compromised.22 Functionality that allows the hypervisor to control and monitor individual VM activity from outside the VMs is known as introspection. Hypervisor introspection expands the functionality of the hypervisor to …

Modified p. 31 → 68

Depending on the particular technology implemented, introspection can provide the ~~CSP~~ with a level of real-time auditing of VM activity that may otherwise be unattainable. This can help the ~~CSP~~ to monitor for and detect suspicious activity within and between VMs. Additionally, introspection may facilitate ~~cloud- efficient~~ implementations of traditional security ~~controls•for~~ example, hypervisor-managed security functions such as malware protection, access controls, firewalling and intrusion detection between VMs.

Depending on the particular technology implemented, introspection can provide the Provider23 with a level of real-time auditing of VM activity that may otherwise be unattainable. This can help the Provider to monitor for and detect suspicious activity within and between VMs. Additionally, introspection may facilitate cloud-efficient implementations of traditional security controlsfor example, hypervisor-managed security functions such as malware protection, access controls, firewalling and intrusion detection between VMs.

Modified p. 31 → 68

Two potential challenges with introspection are that it can bypass role-based access controls and it can be used without leaving a forensic audit trail within the VM itself. For example, to view a data file, a user typically authenticates to the VM, resulting in an authentication audit trail and ~~ensuing~~ the user’s access is controlled according to ~~their~~ defined permissions. If file-access logging is enabled in the VM and the user views a file, the access is recorded to show …

Two potential challenges with introspection are that it can bypass role-based access controls and that it can be used without leaving a forensic audit trail within the VM itself. For example, to view a data file, a user typically authenticates to the VM, resulting in an authentication audit trail and ensuring that the user’s access is controlled according to that user's defined permissions. If file-access logging is enabled in the VM and the user views a file, the access is …

Modified p. 31 → 68

With introspection, files can be accessed from within the privileged state of the hypervisor. As no authentication to the VM itself is required, file access leaves no audit trail on the VM and the VM contains no evidence that the file was accessed. In this example, the access would need to be logged via the introspection tool itself, which would typically not be in the ~~client’s~~ control. While this may be less of an issue within a private cloud environment, …

With introspection, files can be accessed from within the privileged state of the hypervisor. As no authentication to the VM itself is required, file access leaves no audit trail on the VM, and the VM contains no evidence that the file was accessed. In this example, the access would need to be logged via the introspection tool itself, which would typically not be in the Customer’s control. While this may be less of an issue within a private cloud environment, …

Modified p. 32 → 69

~~• February 2013 is~~ maintained. For example, the ability to configure introspection auditing should not be available to personnel with the ability to access hosted VMs via the introspection tool.

Introspection access must therefore be carefully managed, controlled and monitored to ensure that role-based access and segregation of duties are maintained. For example, the ability to configure introspection auditing should not be available to personnel with the ability to access hosted VMs via the introspection tool.

Modified p. 32 → 69

~~CSPs~~ using ~~introspection~~ should be able to provide their ~~clients~~ with all applicable introspection logs for that ~~client’s~~ environment including, but not limited to, authentication details, disk and memory access ~~requests,~~ and API calls. All introspection activity should be mapped to the individual user account performing the activity, and logs should be reviewed on a continual basis to ensure the integrity and confidentiality of ~~client~~ data ~~has~~ been maintained.

Providers using introspection-based products should be able to provide their Customers with all applicable introspection logs for that Customer’s environment including, but not limited to, authentication details, disk and memory access requests and API calls. All introspection activity should be mapped to the individual user account performing the activity, and logs should be reviewed on a continual basis to ensure that the integrity and confidentiality of Customer data have been maintained.

Modified p. 32 → 69

Where introspection is used by a third-party ~~CSP,~~ the ~~clients~~ may wish to consider implementing ~~data- level~~ security controls (such as strong cryptography with all key storage and encryption/decryption operations external to the cloud service) to avoid exposing sensitive data to the enhanced monitoring features that introspection provides.

Where introspection is used by a third-party Provider, the Customers may wish to consider implementing data-level security controls (such as strong cryptography with all key storage and encryption/decryption operations external to the cloud service) to avoid exposing sensitive data to the enhanced monitoring features that introspection provides.

Modified p. 32 → 77

As web services and APIs are by nature publicly accessible, their security is critical to the security of the resources they provide ~~access to.~~ If not properly developed, ~~managed,~~ and secured, these interfaces can be exploited or compromised, resulting in unexpected behavior and potentially unauthorized access. For example, a ~~poorly-coded~~ API could result in weak authentication protocols, poor access ~~controls, and~~ limited auditing capability. Such weaknesses could lead to the exposure of ~~authentication credentials and other~~ sensitive data. If the …

As web services and APIs are by nature publicly accessible, their security is critical to the security of the resources to which they provide access. If not properly developed, managed and secured, these interfaces can be exploited or compromised, resulting in unexpected behavior and potentially unauthorized access. For example, a poorly coded API could result in weak authentication protocols, poor access controls or limited auditing capability. Such weaknesses could lead to the exposure of service functionality or sensitive data. If …

Modified p. 32 → 77

APIs and other public interfaces should be designed to prevent both accidental misuse and malicious attempts to bypass security ~~policy. Strong~~ authentication and access controls, strong ~~cryptography,~~ and real-time monitoring are examples of controls that should be in place to protect these interfaces.

APIs and other public interfaces should be designed to prevent both accidental misuse and malicious attempts to bypass security controls. Resilient authentication and access controls, strong cryptography and real-time monitoring are examples of controls that should be in place to protect these interfaces.

Removed p. 33

Whether unsavory clients can pose a risk to other clients using the same provider will largely depend on the controls the CSP has in place to segregate clients from one another, and to monitor and detect suspicious activity on the shared infrastructure and between client environments. Before engaging with a CSP, clients should consider how the CSP verifies that their clients are who they say they are, and how the CSP detects potentially suspicious behavior once the clients are onboard. Clients should also ask the CSP what controls they have in place to ensure that the security posture of one client cannot affect the security posture of another client.

Removed p. 33

Definitions of what constitutes a breach or incident requiring notification between client and cloud provider should be agreed. Notification processes and timelines should be included in SLAs, and incident response plans should include notification requirements. The potential for client data to be captured by third parties during a breach investigation should also be clearly understood.

Investigating potential breaches in cloud environments brings additional challenges. For example, compromised VM instances may be deactivated before anyone is aware that a breach occurred. It may be nearly impossible to properly investigate a breach when the source of the breach is no longer in use or even exists.

Modified p. 33 → 64

~~• February 2013 6.5.7~~ Multi-tenancy In a multi-tenant cloud environment, ~~client organizations~~ generally have no knowledge of the other ~~clients~~ with whom they share resources (for example, virtual infrastructure, data stores, etc.), or how other ~~clients~~ are securing (or not securing) their environments that access the shared resources.

E.2 Multi-tenancy In a multi-tenant cloud environment, Customers generally have no knowledge of the other Customers with whom they share resources (for example, virtual infrastructure, data stores, etc.), or how other Customers are securing (or not securing) their environments that access the shared resources.

Removed p. 34

• February 2013 7 Conclusion In addition to the business and risk considerations, the implementation of security controls in a cloud environment may require specialized technical knowledge and skills. It is therefore crucial that prior to migrating payment card operations into a cloud environment, an organization engages their technical, legal, due diligence, information security, and compliance teams to work together to define the client’s needs and evaluate potential cloud service offerings against those needs.

Regarding third-party or public clouds, clients should consider that while they can outsource the day-to-day operational management of the data environment, they retain responsibility for the data they put in the cloud.

Clients are encouraged to “shop around” until they find a CSP who can provide the level of security and assurance they require. Potential clients are encouraged to:

 UNDERSTAND your risk and security requirements first.

 CHOOSE a deployment model that aligns with your security and risk needs.

 …

Removed p. 36

Do not use vendor-supplied defaults for system passwords and other security parameters IaaS: Secure configuration of OS and applications is typically responsibility of the client while secure configuration of underlying devices is the responsibility of CSP. There may also be virtual devices that customer is responsible for maintaining.

PaaS: The OS is often controlled by CSP but some services may include a level of client access to OS•both parties will need to clarify which entity is applying secure configuration and hardening at the OS level. Applications and software above the OS are likely to be controlled by the client. Secure configuration of network devices will be managed by the CSP.

SaaS: The CSP typically manages configuration and hardening of all devices, OS and applications.

Client and CSP Client and CSP CSP

Protect stored cardholder data IaaS and PaaS: The client is generally responsible for the manner in which information is secured (such as the …

Removed p. 38

Develop and maintain secure systems and applications IaaS: Patching and maintenance of OS and applications are typically the responsibility of the client, while patching and maintenance of underlying devices remains the responsibility of the CSP. There may also be virtual devices that the client is responsible for maintaining. Secure coding is typically the client’s responsibility (they may either use their own applications or choose secure commercial applications).

PaaS: Patching and maintenance of underlying devices remains the responsibility of the CSP. OS patching and maintenance may also be controlled by CSP; however, some PaaS services include client responsibility for OS maintenance•entities will need to determine which party is responsible for applying patches/updates. If the CSP provides patching, the client should verify that patches are deployed in a timely manner. Patching of applications is typically managed by the client, depending on the service and agreements. Secure coding of application is the responsibility of …

Removed p. 39

Client and CSP Client and CSP Client and CSP

Assign a unique ID to each person with computer access IaaS and PaaS: The client is responsible for ensuring all accounts under their control use unique IDs and strong authentication. The CSP is responsible for ensuring strong authentication is used for the underlying infrastructure.

Compared to the IaaS model, the CSP retains significant administrative access rights In SaaS and PaaS models.

SaaS: The CSP has ultimate control of accounts at all levels. Depending on the particular service, the client may have the ability to create user-level accounts within the application or service, or they may be assigned user accounts that the CSP maintain on their behalf. The client is responsible for ensuring all the accounts they use have strong passwords.

Restrict physical access to cardholder data All service models: Generally managed by the CSP for all service models. The client rarely has any physical access …

Removed p. 41

• February 2013 Appendix B: Sample Inventory This appendix provides an example inventory for components used in cloud environments. Use of an inventory can help to identify the types of components involved in delivery of the service and responsibly for securing them. This example is not intended to be applicable to any particular scenario, and is intended to provide a starting point for scoping discussions between clients and CSPs.

 The type of information collected should be relevant for the client’s business needs as well as the CSP’s  The level of detail collected should be appropriate for both parties to reach a clear understanding of the components involved, their use, and who manages/secures them.

Note: Actual layers will vary depending on structure of CSP service offerings For example:

Is component physical, logical or virtual? Static or dynamic? Number of components used in relation to client’s Defined usage, location, etc., as applicable For …

Removed p. 42

• February 2013 Type/Layer Component Description/Purpose Type of Component Number of components Implementation Notes Responsibility for securing component

Note: Actual layers will vary depending on structure of CSP service offerings For example: Firewall, OS, application, web server, hypervisor, router, database, etc.

For example: Is component physical, logical or virtual? Static or dynamic? Number of components used in relation to client’s Defined usage, location, etc., as applicable For example: CSP only, client only, Processing/Memory Data Storage Network devices Physical facilities

• February 2013 Appendix C: Sample PCI DSS Responsibility Matrix A PCI DSS responsibility matrix may help to clarify and confirm how responsibilities for maintaining PCI DSS requirements are shared between the client and CSP. Responsibilities should always be defined in written agreements.

 Does the CSP perform/manage/maintain the required control?

 How is the control implemented, and what are the supporting processes? (E.g., process for patch updates would include details of testing, scheduling, approvals, etc.) …

Removed p. 44

PCI DSS Requirement Responsibility (CSP only, client only, or shared) Specific coverage/ scope of client responsibly Specific coverage/ scope of CSP responsibility How and when CSP will provide evidence of compliance to Client 1.1.3 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone 1.1.4 Description of groups, roles, and responsibilities for logical management of network components 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

Removed p. 44

Note: This is intended as an example only to provide a starting point for discussions between clients and CSPs. It is not intended as a requirement or an extension of PCI DSS compliance responsibilities. However, it may provide a useful tool to help to clarify responsibilities in agreements between clients and providers.

• February 2013 Appendix D: PCI DSS Implementation Considerations The questions in this appendix are intended as suggestions to help start conversations between clients and CSPs in order to understand the characteristics of a particular cloud environment, which may in turn help determine if and how PCI DSS requirements can be met in that environment. These questions alone will not determine whether or not applicable PCI DSS requirements can be met, however, they may be a useful addition to questions directly related to specific PCI DSS requirements.

 CSA Consensus Assessments Initiative Questionnaire  ENISA Information Assurance Requirements Please also …

Removed p. 46

PCI DSS Requirement Considerations for Cloud Environments Protect Cardholder Data 3: Protect stored cardholder data 4: Encrypt transmission of cardholder data across open, public networks  Where are the “known” data storage locations? Where are data centers located?

 Which legal jurisdiction(s) applies to client data?

 Does the CSP have any business, legal or regulatory requirements that could impact retention of client data?

 How is access to client data restricted to only that client’s users and applications?

 How are VM images, snapshots, and backups managed to prevent unnecessary capture of sensitive data?

 How is data securely deleted from memory and stored images? Will data remnants exist in terminated VMs?

 If cryptographic keys are provided by CSP, are unique keys generated for each client?

 Where are encryption/decryption processes being performed? Who controls each process?

 Where are cryptographic keys stored, and who controls the keys? Are data-encryption keys stored and managed separately from …

Removed p. 47

PCI DSS Requirement Considerations for Cloud Environments Implement Strong Access Control Measures 7: Restrict access to cardholder data by business need to know 8: Assign a unique ID to each person with computer access 9: Restrict physical access to cardholder data  How is user authentication applied at different levels?

 How are layers of access controls managed to ensure the aggregate access is not more than intended?

 Which CSP personnel have ability to access client data?

 How are CSP privilege assignments reviewed and monitored?

 How is segregation of duties maintained (for example, between administrative and auditing functions)? o Is administrative access to systems or hypervisor separate from access to client VMs and data stores? o Are separate credentials used for different security functions?

 How are least-privilege and need-to-know determined for CSP personnel?

 How are credentials de-provisioned? o Does de-provisioning apply across all geographically distributed locations? o Could de-provisioned credentials be …

Removed p. 48

PCI DSS Requirement Considerations for Cloud Environments Regularly Monitor and Test Networks 10: Track and monitor all access to network resources and cardholder data 11: Regularly test security systems and processes  How are activities traced back to individual client personnel or individual CSP personnel?

 Can the specific system components used by a client at a particular time be identified?

 What types of events are recorded in audit logs?

 How are audit logs correlated between client environments (such as a VM image) and CSP infrastructure (such as the hypervisor or underlying system)?

 How are audit logs monitored and reviewed?

 How are clocks synchronized between virtual instances and underlying systems/hardware?

 How is testing for wireless technologies performed and managed?

 How are all variations of VM images (including inactive VMs) scanned for vulnerabilities?

 What defenses are in place to protect against ‘internal’ attacks (originating from CSP’s or other client network) and “external” …

Removed p. 49

PCI DSS Requirement Considerations for Cloud Environments Maintain an Information Security Policy 12: Maintain a policy that addresses information security for all personnel  How does the CSP identify potential risks?

 Are clients notified upon changes to the CSP’s security and/or privacy policies?

 Does the CSP have mechanisms in place to ensure secure operational procedures are followed?

 How does the CSP screen personnel? o Are different levels of screening used for different roles or regions? o Does screening cover all personnel with physical access to data centers at all locations?

 Does the CSP outsource any aspect of the cloud service to other providers (e.g., data storage, security services, etc.)?

 What measures are taken to ensure that the CSP’s security policies are maintained by their third-party providers?

 What processes are in place to detect, assess, escalate, and respond to potential breaches? o What mechanisms are in place for clients to report …

Modified p. 50 → 79

PCI SSC would like to acknowledge the contribution of the Cloud Special Interest Group (SIG) in the preparation of this ~~document. The~~ Cloud ~~SIG consists of representatives from the following organizations:~~

PCI SSC would like to acknowledge the contribution of the Cloud Special Interest Group (SIG) in the preparation of this document, which is a revision of the document prepared by the 2013 Cloud SIG.

Modified p. 51 → 82

References This document draws the following additional ~~sources of reference.~~ These sources are recommended as ~~additional~~ guidance on securing cloud-computing environments.

Additional References This document draws upon the following additional references. These sources are recommended as further guidance on securing cloud-computing environments.

Modified p. 52 → 83

About the PCI Security Standards Council The PCI Security Standards Council is an open global forum that is responsible for the development, management, ~~education,~~ and awareness of the PCI Data Security Standard (PCI DSS) and other standards that increase payment data security. Founded in 2006 by the major payment card brands American Express, Discover Financial Services, JCB International, ~~MasterCard~~ Worldwide, and Visa Inc., the Council has over 600 Participating Organizations representing merchants, banks, ~~processors,~~ and vendors worldwide. To learn more …

About the PCI Security Standards Council The PCI Security Standards Council is an open global forum that is responsible for the development, management, education and awareness of the PCI Data Security Standard (PCI DSS) and other standards that increase payment data security. Founded in 2006 by the major payment card brands American Express, Discover Financial Services, JCB International, Mastercard Worldwide, and Visa Inc., the Council has over 600 Participating Organizations representing merchants, banks, processors and vendors worldwide. To learn more …

Document Comparison

From Revision History

Content Changes