As promised in a prior Cyderes blog post from March 24 of this year, Cyber Playbook: An Overview of PCI Compliance in 2022, the PCI Security Standards Council (SSC) has finally released to the public a significant rewrite of the PCI Data Security Standard (DSS).
PCI DSS v4.0 is perhaps the most significant rewrite in the history of the standard. Many things have stayed the same, but some things have changed measurably. To the council’s credit, there are many improvements and additional clarifications included within v4.0 content. They’ve also included a major paradigm shift for merchant and service providers attempting to meet the spirit and intent of all requirements in PCI DSS v4.0. One can find a detailed taxonomy of all the changes in the standard here.
So, let’s first look at content improvements:
Executive Summary 4: The Scope of PCI DSS Requirements has been further expanded and expounded upon, including direct references to cloud and container architectures, references to Software as a Service (Saa), and “Tools, code repositories, and systems that implement software configuration management or for the deployment of objects to the CDE or to systems that can impact the CDE.”
Accurate PCI scoping determinations have historically been challenging as cardholder data environments and components have evolved at a highly accelerated pace. The lack of the newest clarifications often led to a bit of contention between merchant/service provider scoping assertions, and their PCI Qualified Security Assessors (QSAs). The PCI DSS has now been updated with many new content references to determine what truly is and is not in scope.
Another PCI DSS improvement referenced in the previous blog post is the risk associated with client-side web browser vulnerabilities. The client-side web browser has traditionally been omitted from established web application security and penetration testing methods. This not-so-new ‘attack surface’ has been exploited by malware creators, hackers, unscrupulous marketers, and even social companies for years. In addition, there have been highly publicized corporate payment application web page breaches that leveraged client-side vulnerabilities for ill-gotten gain. While the PCI SSC has publicly acknowledged a genuine concern over this type of exploitation, they had not formally incorporated security validation requirements within the PCI DSS, until now,
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
There are tools and methods to help with this which are referenced in the previous blog post. The most important thing is that the PCI SSC has now officially recognized and validated the importance of securing the client-side web browser as it relates to ecommerce payment web pages. Also, while not specifically referenced, it is incredibly important to apply the same requirements and controls to ‘payment redirection web pages’. There have been many noted breaches of ecommerce payment redirection pages that led to some high dollar losses for some marquis corporations. Also worthy of note; the PCI SSC has also qualified the expected time frame for meeting these new requirements,
“This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.”
This will give PCI ecommerce merchants and service providers a bit of time to create and implement a plan to meet these new requirements in the future. It is strongly urged that they start working on this now. Doing so will reduce potential exposure to this attack surface and ensure compliance before the deadline arrives.
Now, let’s consider a change to the PCI DSS that can only be described as a major shift in assessment requirements and validation focus. The new standard still embraces what the PCI SSC has referred to as the ‘standard’ approach to compliance, and that relates to ‘business as usual’. It entails the same approach the PCI ecosystem has embraced since its original inception.
The new standard has also introduced what is called the ‘customized approach’ to PCI DSS compliance. What the customized approach enables a merchant or service provider to do is create their own security controls that would provide equal to, or better protection than the original security controls. With PCI DSS v4.0, they can apply the customized approach to a single requirement, selected requirements, or to all assessment requirements. The caveat is that they must complete and document a comprehensive risk assessment to be able to prove that their customized approach is valid for each implementation of this approach. This is about to get very interesting for all interested parties.
Enterprise security teams are adapting to meet evolving business needs. With six global Security Operations Centers, emerging technology partners and a dedicated team of security specialists, Cyderes is well-positioned to be your organization’s trusted advisor in cybersecurity. We’ll help you understand your risk exposure, increase your visibility and ROI, and proactively hunt for the latest threats.