In late 2020, the PCI DSS v4.0 will be released. And in what promises to be an even more significant change than that from 2.0 to 3.0 (released in Nov. ’13), there is, rather unsurprisingly, a great deal of interest in its contents.
So what’s in it?
I’ll be honest, I can’t tell you, or more to the point, I’m not ALLOWED to tell you as the draft version is currently in ‘Request for Comment’ (RFC) status. Yes I have read it, not only that, I have mapped it line-by-line to v3.2.1 and analysed the differences in detail. I have even written a brief on what I consider the impact of those changes will be, but it will have to remain unread until the moratorium is lifted.
Now that you’re pissed off and disappointed, some good news; It is actually quite easy to extrapolate the evolution of both the threats to the payment card industry and the PCI DSS itself into a common sense approach to get out ahead next year’s release.
But first, you have bear a few things in mind:
- The PCI DSS has always been, and will always be a “minimum set of requirements for protecting account data“, therefore if all you have ever done is meet those minimums, any change is going to create work for you;
- As a corollary to 1., there is nothing in the PCI DSS that you should not already be doing, not just for PCI compliance, but for all data assets critical to the business. So, if you treated PCI compliance as a tick-box exercise, you are completely unprepared for what’s to come;
- If you were doing security properly there’s nothing the SSC could add to the DSS that would not already be covered, even if it was just a line item in your risk register;
- Just like security in general, the PCI DSS will never keep up with the threat landscape (good guys have limitations, bad guys do not), so you only have to look at the highest risks to cardholder data to understand where the next DSS is going to focus;
- The DSS has had 15 years to stop the bleeding as much as possible, now it’s time to fit the maintenance of it into a more ‘flexible’ risk framework, which it is, per the SSC’s stated goals;
- “Ensure the standard continues to meet the security needs of the payments industry;
- Add flexibility and support of additional methodologies to achieve security;
- Promote security as a continuous process;
- Enhance validation methods and procedures“
Given the above, as well as the example control topics the SSC provided…:
- “Authentication, specifically consideration for the NIST MFA/password guidance;
- Broader applicability for encrypting cardholder data on trusted networks;
- Monitoring requirements to consider technology advancement;
- Greater frequency of testing of critical controls“
…what is likely to change most in my opinion:
Prediction 1: There is no way you can support the goal of ‘promot[ing] security as a continuous process‘ unless you have the following in place:
- Some form of governance, or at least a growing culture of individual accountability;
- Robust Policies (cultural definition), Standards (systems baselines), and Procedures (corporate knowledge);
- Comprehensive risk management processes – or you’ll never be able to define ‘appropriate’.
Guidance: You should therefore expect enhancements to the DSS requirements that contain; “Examine documentation…“, “Interview responsible…“, or impact risk management.
Prediction 2: There is no way you can support the goal of ‘Ensur[ing] the standard continues to meet the security needs of the payments industry‘ unless you up the ante on the more egregious gaps in security capability.
I have previously defined these as some of those gaps:
- The PCI DSS only covers POST-auth data, not PRE-auth data;
- Weak change control;
- Ineffective logging and monitoring; which leads to
- Weak incident response;
- Entirely manual process for data asset management;
- and so on…
Guidance: Unless you can demonstrate that the PCI minimums are appropriate security for your organisation’s unique risk profile, you should consider bringing some of the more egregious control gaps up to some of the established industry good practices.
Prediction 3: The SSC’s stated control topic of “Monitoring requirements to consider technology advancement” can only suggest that technology now needs to play a greater part in PCI compliance. The DSS requirements that include an aspect of ‘monitoring’ include:
- Third party access;
- Physical access;
- Failure of security controls (service providers only);
- ‘Rogue’ wireless access points;
- and so on…
Guidance: It stands to reason that while compliance with some of the DSS requirements could previously be more of a manual process, the increased availability and the decreased cost and complexity of ‘monitoring technologies’ may render their continued lack of use inappropriate.
Not that the SSC will ever make a specific technology mandatory, you have to work out how best to meet the DSS’s intent.
Prediction 4: The control topic; “Broader applicability for encrypting cardholder data on trusted networks” can only mean one thing; encryption of cardholder data ‘on the wire’ is going to be required across trusted networks as well as untrusted.
Guidance: If this does make it to the final version, you will [I suspect] have 2 years to implement it. Start now, and not because the DSS might say so, but because encryption of important data assets across ANY network is the right thing to do.
Prediction 5: The control topic; “Authentication, specifically consideration for the NIST MFA/password guidance” does not mean you don’t have to change passwords anymore, it means you will have to revamp your entire authentication infrastructure in line with current best practices. Passwords of 7 characters, upper/lower case, history of 4 etc. are not adequate in NIST’s eyes, not that they ever were.
Guidance: Going above the DSS minimums with regard authentication is easy. From simple things like upping the password length/history/lockout, to enforcing MFA across the enterprise, to use of more appropriate authentication factors, this is yet again something that is right for the business.
I have to stop here as I must be careful not to give away any detail, but I can state categorically, that if you were doing security properly there is NOTHING in v4.0 that would be an issue for you.
Further, if you were to integrate your ‘GDPR compliance’ efforts with your ‘PCI project’ you would have everything you need from both a governance AND a technology perspective.
And the best thing about this is that you don’t have to wait to find out what’s in v4.0, a good security consultant could tell now what your gaps are.
[If you liked this article, please share! Want more like it, subscribe!]