Three ways to reduce your PCI scope in Google Cloud
My team and I have published a new reference guide on Limiting scope of compliance for PCI environments in Google Cloud.
What is PCI DSS?
PCI Data Security Standards (DSS) are a set of standards that companies must comply with in order to process credit card transactions on the web. PCI DSS consists of 12 requirements categories that in-scope systems must meet in order to pass a PCI assessment. An assessment is done, at least annually, to ensure that the systems that process credit card transactions remain in compliance with these standards.
What is PCI scope?
The first step of any assessment is to identify and verify the scope — that is, the invisible line that separates in-scope from out-of-scope systems. In-scope are assessed for PCI compliance, and out of scope systems are not assessed. In-scope systems are regarded as trusted systems. By trusted, we mean that any compromise of these could lead to exposure of cardholder data. Out of scope systems, on the other hand, are untrusted. Untrusted systems have zero value to an attacker, and the compromise of an untrusted system cannot lead to exposure of cardholder data.
The security of all systems is important, but for purposes of PCI compliance, in-scope systems are assessed according to the 12 PCI DSS requirements.
Why reduce scope?
Simply put, smaller scope is better. Reducing the footprint of your trusted systems also leads to a smaller attack surface, and is more closely aligned with a robust defense-in-depth strategy. This leads to better overall security, reduced complexity and risk, and reduced cost of attaining and maintaining PCI compliance.
Scope Reduction Strategies
Correct scoping requires a clear and defensible separation between in-scope and out-of-scope systems. All scope reduction strategies revolve around the theme of clearly segmenting and isolating untrusted systems in your cloud environment so that they cannot impact the security of trusted systems. In addition to these strategies below, PCI offers supplemental guidance on scoping and segmentation on their website.
1. Resource Hierarchy Isolation
In Google Cloud, the Resource Hierarchy can be used to logically isolate untrusted projects and folders from your in-scope systems. Create a single folder called “PCI Compliant Systems”, deploy all in-scope systems into projects within that folder, and ensure only designated users have access to that folder.
Within your trusted systems, you’ll have a cardholder data environment (CDE) which stores and processes actual cardholder data, such as credit card numbers. Put your CDE in its own project, segmented from other aspects of your PCI systems such as fraud monitoring and fulfillment.
2. Network Segmentation
PCI DSS requirements 1 and 9 require that you separate your cardholder data environment network from other networks, and maintain a firewall to protect it. Segmenting your networks properly can also be an effective way to reduce your compliance scope.
Put your CDE in its own Virtual Private Cloud (VPC) network, and isolate subsystems using subnets and firewalls. Implement VPC service controls to protect unauthorized access or exfiltration of sensitive data.
3. Cardholder Data Tokenization
In a PCI environment, cardholder data (CHD) should be treated as metaphorical toxic waste. That is, you want to store and transmit it only where and when absolutely necessary. Often, though, other systems such as order fulfillment and fraud detection rely on transaction information, and need to be made aware of specific transaction details. Before sending the transactions to any other system outside of your CDE, understand how to tokenize the CHD in order to maintain segmentation between your CDE and out-of-scope systems.
For a complete solution for how to employ these strategies in your own Google Cloud environment, see our reference guide: Limiting scope of compliance for PCI environments in Google Cloud.