Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Act Now: Leveraging PCI Compliance to Improve Security
Let the threat landscape guide your company's timeline for complying with new data security standards for credit cards. Use the phase-in time to improve security overall — security as a process — not just comply with new standards.
May 26, 2022
4 Min Read
Source: Aleksey Funtap via Alamy Stock Photo
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 22.214.171.124 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.
About the Author(s)
VP of Strategy, Tripwire
Tim Erlin is VP of Strategy at Tripwire. He previously managed Tripwire's Vulnerability Management product line, including IP360 and PureCloud. Erlin's background as a sales engineer has provided a solid grounding in the realities of the market, allowing him to be an effective leader and product manager across a variety of products. His career in information technology began with project management, customer service, as well as systems and network administration. Erlin is actively involved in the information security community. His contributions include blogging, podcasts, press, speaking, and television.
You May Also Like
Your Everywhere Security guide: Four steps to stop cyberattacksFeb 27, 2024
Your Everywhere Security Guide: 4 Steps to Stop CyberattacksFeb 27, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
Securing the Software Development Life Cycle from Start to FinishMar 06, 2024
Laptop with ransomware, and bitcoin in the palm of a man's hand to illustrate ransomwareCyberattacks & Data Breaches