Why PCI DSS 4.0 Needs to be a Complete Rewrite

The last month has been tough for our coastal regions and based on what forecasts show for the rest of the season, we’re not out of the woods. If you have not donated to those affected by these massive storms, please consider doing so today. The group that received my donations this time around is Direct Relief, but there are plenty to choose from.

There – I Fixed It, by dierken

Thankfully, the Council canceled the Community meeting due to Irma (albeit, probably two days too late). It was the right decision. Hopefully, the vendors who have spent money with the Council will get some kind of relief for this year.

Given that the conference didn’t happen, there was a missed opportunity to discuss the future of PCI DSS (although, history says it may not have been productive—especially with the lack of a GM). Regardless, it’s time for a serious discussion on the future of PCI DSS. I posit that it needs a complete overhaul. Here’s why:

  • It’s lost its relevance given the way we do business today. The first version was released on December 15, 2004, and while it’s gone through changes with new requirements, it’s remarkably close to the original release. Would you say your IT environment today looks remarkably close to the environment you managed in 2004, the same year that Facebook was launched? Probably not. New technologies are either missing or ignored, and the Standard oversteps its scope a bit.
  • Breaches are still happening to merchants on a weekly basis. All you need to do is follow Krebs to validate. If we want to blame that on low compliance rates, then the Standard needs to change to help boost them.
  • QSA Assessment quality is still an issue as recent updates to the QSA Certification Requirements now require an additional certification (one security, one audit) to be a QSA. This gives companies a false sense of security in that they receive assurance they are compliant with PCI DSS, but in fact, they are not. Often times this is done with merchants’ tacit approval.

Spoon, by felixtsao

As an example, the latest revision of PCI DSS—version 3.2—was a crackdown on service providers. It’s gotten worse for them with each passing version of the standard. It increasingly brings a Checkbox Security mentality to those firms as opposed to promoting financially strong and responsible service providers.

Perhaps service providers should be subject to the equivalent of a bank solvency stress test instead of prescriptively telling service providers what to do. Can the service provider survive a breach? If so, let them secure their platforms however they want so they can deliver services to merchants and other players in the space. If not, they need to improve their cap structure or insurance coverage to make up the difference.

To those who may think this is risky, remember that NOBODY wants to go through a breach. That said, no responsible infosec or GRC person thinks PCI DSS (or any compliance standard) will keep you breach free. So instead of managing to a standard we know won’t keep us 100% safe, why not look to the survivability of these companies and let them manage their technology the way they know how?

This will likely have the impact of weeding out a few shops that run lean margins. Financial stability can still be achieved with lean margins. Service providers that fall out of compliance with PCI DSS and suffer a breach can cause serious damage to the ecosystem. Financially strong versions can survive.

Bottom Line:

The following framework might be a good place to start:

  • The new version should take advantage of advanced P2PE or E2EE technologies and allow merchants who use these technologies to be automatically compliant.
  • Incentivize the right behavior in technology to protect the ecosystem, and allow those who follow those incentives to be free from the burdens caused by PCI DSS.
  • It should be shorter, more concise, and with fewer variations.
  • It should stay inside the payment card swim lane and not try to expand beyond the payments space.
  • It should promote technologies that secure data while allowing the merchant to safely use it during their day-to-day operations.
  • It should allow Acquirers to manage their merchant breach risk in a manner that works for their business (perhaps stress tests for them as well).
  • It should have a better supporting ecosystem of documentation that is easier to navigate and has clear Policy -> Standard -> Procedure -> Guideline format, all enforceable through the baseline policy with details on specific technologies and their Dos and Don’ts.

Mostly, it should be easy for any merchant, big or small, to understand what they need to do to protect payment card data. Make it easy, and compliance rates will fly through the roof. Make it well and high compliance will result in lower breach rates.


This post was originally published on this site
Comments are closed.