Leveraging PCI Compliance to Improve Security

In March, the PCI Council released the latest update to its Data Security Standard (DSS). The PCI DSS 4.0 is a major refresh of the current version, 3.2.1, which was released in May 2018. The threat landscape has certainly changed in the last four years, so it's not surprising to see significant changes to this version of the DSS, which is meant to reduce the risk of debit and credit card data loss and protects merchants and cardholders.

However, none of the changes in version 4.0 will require immediate action. Version 3.2.1 won't be retired until the second quarter of 2023, and many of the newer requirements in version 4.0 are considered best practice — i.e., not required — until March 2025. For affected organizations, it's not uncommon to see this deadline and create a plan based on an extended, two-year timeline. That said, delaying implementation is also the strategy that includes accepting the most risk.

Full Compliance Is Difficult
The reality is that compliance with version 3.2.1 hasn't been an easy task for most organizations. Verizon's most recent "Payment Security Report" (registration required), published in 2020, found that only 27.9% of organizations were able to maintain full compliance with the PCI DSS, which is down 8.8% from the prior year. That decline is part of a longer trend, with compliance down 27.5% since 2016, when full compliance peaked at 55.4%.

Faced with this reality and the changes in version 4.0, there's an opportunity for organizations to take a different approach through this transition. Rather than creating a plan to meet compliance deadlines, organizations should create a plan to improve security that also meets compliance requirements. It's rare to have this kind of runway for a requirement, and it's an opportunity that shouldn't be squandered.

To illustrate this point, it's important to look at the changes to the DSS in groups, and by identifying trends. After all, these changes aren't arbitrary. They've been carefully made based on the threat landscape.

As an example, there are three changes to consider. First, Requirement 2 has been updated from "Do not use vendor-supplied defaults for system passwords and other security parameters" to "Apply secure configurations to all systems." Requirement 8.3.9 now provides an option to use dynamic assessment of security posture of assets in place of password rotation. Finally, Requirement 8.5.1 specifies secure configuration requirement for the implementation of multifactor authentication.

It's possible to consider each of these changes as separate items to be addressed in a transition plan, but they collectively point to a common underlying security control: security configuration management. Rather than address them individually, an organization should implement a comprehensive SCM program that also meets compliance needs. As a relevant aside, the Center for Internet Security documents in its Community Defense Model "that establishing and maintaining a secure configuration process (CIS Safeguard 4.1) is a linchpin Safeguard for all five attack types, which reinforces the importance of configurations, such as those found in the CIS Benchmarks." In other words, there's more security benefit to be gained than just PCI compliance.

There are certainly other examples to consider as well. Requirement 8.3.9 might be combined with Requirements 8.4 and 8.5 around MFA to drive a more comprehensive zero-trust architecture (ZTA) project. PCI compliance certainly doesn't require ZTA, but the data suggests that security can be enhanced with a best-practice ZTA implementation. By prioritizing a security-oriented objective and using the transition in PCI as a driver, organizations can maximize their benefits from a required project.

This type of a strategy isn't limited to new requirements, either. The Verizon report shows that Requirement 11, "Regularly Test Security Systems and Processes," has been the most problematic for organizations since the report's inception 10 years back. While one could argue that there haven't been major changes in Requirement 11, there are certainly changes that will cause work. For example, Requirement 11.3.1.2 now requires authenticated vulnerability scanning for internal assets. Such changes present an opportunity to address long-standing obstacles to both security and compliance with a more comprehensive approach to vulnerability management.

Compliance as Tool, Not Burden
The other side of the equation is the cost of addressing the changes as individual requirements. It's possible to take the full two years to implement some of these requirements and remain fully compliant with PCI, but doing so also adds avoidable risk to your business. First, you're not escaping PCI compliance in the meantime. You'll simply have to comply with version 3.2.1, which still consumes resources. More importantly, the changes in version 4.0 were made to address the threat landscape we currently face, and by delaying implementation of things like expanded MFA and monitoring of security controls, you're allowing recognized, known risks to persist in your environment.

While PCI compliance serves to protect the card brands themselves, the security controls you choose to implement should protect your organization and its data. Set security as the priority and leverage compliance as a tool rather than seeing it as a burden.

Results for “"phase-in"”

Act Now: Leveraging PCI Compliance to Improve Security