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:
- Access Management: The latest industry best practices for password and multi-factor authentication, including multi-factor authentication for all user access, updated password rotation frequency, updates to the length and complexity of secrets, and specifications for the review of logs and vendor access.
- Risk Assessment: Risk assessments may require more human intervention to avoid the output from tools as being the sole criteria for an assessment.
- Emerging Technology: A potential change would allow for customized controls based on intent to meet the security guidelines of the standards. This would allow organizations new flexibility to adopt emerging technologies or security solutions to meet objectives based on the intent.
- Testing: Documentation for tests will have better criteria for sampling, and date source scoping to ensure proper coverage for the target environment.
- Scoping: The scope of PCI DSS is assessed at least once every 12 months, every three months for service providers, and promptly for both upon significant changes to the environment.
- Training: Organizations must update cybersecurity training for end-users to include relevant information regarding current threats and vulnerabilities, including phishing and social engineering that could impact the cardholder and processing environment.
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:
- All data sources and computing services are considered “resources.”
- Security teams secure all communications (internal or external), regardless of source and destination.
- Access gets granted on a “per-session” basis.
- Users gain access based on a dynamic risk-based policy.
- All devices are in the most secure state possible and continuously monitored.
- Security teams strictly enforce dynamic authentication and authorization before granting access.
- Make logging and monitoring about the network and infrastructure as granular as reasonably possible.
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
