In the first quarter of 2022, the PCI Security Standards Council (PCI SSC) will publish the PCI DSS v4.0 standard. Within the specification, there are some significant changes that every organization should take into consideration.
The following are most likely to be included in the final release:
While just a brief summary of what to expect, security teams should consider the emerging technology changes as a red flag for any organization considering implementing zero-trust architectures in their cardholder environments or for payment processing. Here’s why:
First, the burden of proof will be on the organization to prove intent and convince the auditor that the implementation actually meets or exceeds the intention of the specification. While this burden may sound like a simple nuance, it will become problematic if the changes are rejected by an auditor who deems the solution does not meet the requirements. An escalation process to dispute the results needs clarification. And if the emerging technology fails in escalation or arbitration, organizations may need to re-engineer or replace the solution with something less ideal or not fully in line with their future plans. If the organization considers zero-trust architectures as an emergency technology, the risk of “proof” could fit squarely on the company’s back as a risk to the organization.
Now consider the notion of zero-trust as an emerging architectural technology. Zero-trust as implementation and workflow has been well documented by NIST 800-207. It provides a standard path for the entire community. So it’s critically important to remember zero-trust is not a product, but rather a strategy and implementation to achieve a high confidence in authentication and behavior based on these seven tenants:
What creates the potential conflict with PCI DSS version 4.0 Emerging Technologies are the hypothetical conflicts with No. 2 (secure communications) and the existing PCI DSS standard regarding PCI Zones and Segmentation.
For starters, PCI DSS security practices prescribe that all cardholder data and processing information get stored in a secure network zone with proper segmentation and network security controls. In zero-trust terms this is an Enclave in which all communications are proxied, brokered, managed, monitored, and logged for appropriate behavior. While it’s possible to consider these two concepts compatible and defendable for a PCI DSS v4.0 audit, they would fail miserably if companies embrace the pure definition of zero-trust where there’s no perimeter and network controls are not used for segmentation. In other words, no resource segmentation exists, no PCI zone, and security gets managed at the resource level only via a zero-trust architectural model.
Therefore, security teams cannot implement a cardholder environment, nor the processing of payment data using zero-trust as an emerging technology. The results are not defendable unless the security team treats the PCI Zone as an Enclave since a PCI Zone must have defined segmentation and network controls. And if the security team does that and embraces an Enclave model, it’s probably not doing anything different than it does today by providing a gateway or bastion host into the PCI environment in the first place. After all, the PCI Zone with all the existing controls is by definition an Enclave. NIST 800-207 clearly defines that.
While we await the final standards publication from the PCI SSC, security and information technology professionals need to understand the nuances of security initiatives like zero-trust to solve and satisfy the emerging technologies concept in PCI DSS v4.0. A pure interpretation of a zero-trust architecture will create a potential conflict. Additional zero-trust architectures like the Enclave model appear compatible, but the results will have to be defendable, especially if the communications originate outside of the security team’s control. This could create additional burdens of proof for vendor access or even administrators working from home. There’s a conflict arising between the two standards and from initial publications. One still wants to enforce network zones and segmentation and the other does not.
Morey Haber, chief security officer, BeyondTrust