Version 4.0 of the PCI DSS has been a long time coming, and still won’t be here for a while yet. The PCI Council is actively engaging with the community to develop the new version of the standard through their RFC – Request For Comments – process.
Unfortunately, you won’t see much if anything discussed in public about the proposed changes. This is because for current purposes, “the community” is an exclusive set of companies and people – those who have paid for Participating Organization or other membership of the PCI Council. All drafts of the new standard are released to members under NDA, prohibiting them from being discussed in public.
The council has already been though one RFC round, starting in late 2019. They have reviewed the responses, and incorporated some of this feedback into the second draft. It is this second, revised draft that was released to members for their comments on 23 September 2020.
Contents
What do we know about the proposed changes?
Frankly, not that much is publicly known. Most of what is being openly discussed is speculation, as those who actually are in a position to actually comment are prohibited from doing so by their NDA. The best place to look for those who are interested is the blog post from the PCI Council responding to feedback in the first RFC round.
One key statement from that blog post is that PCI DSS 4.0 aims to “reinforce security as a continuous process”. Historically, PCI compliance has always been seen, probably to the detriment of overall security, as a point-in-time assessment. Essentially, the view was that as long as the documentation was in order for the QSA on-site visit, and quarterly passing scans were available, the job was done.
More recently the Council has tried to create more of a focus on security as a BAU activity. With that statement in the blog post, we can be confident that this trend will continue. What does that mean in practice? Unless the overall assessment methodology is to change, it likely means more of the line items in the testing procedures will require samples taken over time during the previous year, rather than at the point of the current assessment.
Beyond this, in the same blog the Council has a bulleted list of topics that generated a lot of feedback. Note that they don’t make clear what either the proposed change was, or the nature of the feedback! However, for some we can make educated guesses.
Requirement 4 Changes
- Requirement 4: Protect cardholder data (CHD) with strong cryptography during transmission
- Protection for all transmissions of CHD
- Use of self-signed/internal certificates
I read this to mean that we will be required to encrypt transmission of CHD over our private networks, as well as public. That’s a general industry trend in any case, and makes sense to me as an operator of a modern platform. I can see this causing issues for legacy systems designed with the assumption that private networks are inherently trustworthy.
The comment on self-signed certificates is interesting. I suspect some people will be pushing to allow self-signed certificates on private networks, as this achieves the encryption requirement without the need for centrally managed PKI. Others will be pushing back on this, as self-signed certs may provide for encryption but they don’t establish trust.
Personally I think they should permit self-signed certificates on private networks, at least for now. My thinking is that an incremental approach of first permitting self-signed certificates ensures that traffic can be encrypted in transit sooner. This immediately upgrades confidentiality, because currently PANs in transit can be encrypted with a passive attack (network sniffing). Using TLS, even with a self-signed certificate, now requires an active MITM attack to intercept the same data.
Requirement 8 Changes
There are a number of items in Requirement 8 that received lots of feedback. The key one that stands out to me is:
Requirement 8: Identify users and authenticate access
- Password length, history, and change frequency that aligns with industry guidance
I assume what this means is the removal of the requirement to change passwords every 90 days. This would be in line with modern password guidance, such as that in NIST Special Publication 800-63B. That is, to not force regular changes, so that users are more likely to pick a strong password rather than a simple sequence-based one.
Since MFA (Multi-Factor Authentication) is already mandatory for remote access, there’s really no need for both regular password rotation, as there is also a secure second factor in any case. Removing the need to regularly change passwords is something I would approve of.
Requirement 11 Changes
There is one item listed against Requirement 11:
- Requirement 11: Regularly test security systems and processes
- Authenticated scanning for vulnerability scans
Currently, vulnerability scans are permitted to use either unauthenticated or authenticated access. The assumption with this feedback has to be that there is at least a proposal to make authenticated scans mandatory.
I can see good arguments for requiring authenticated scans. But, this opens up a whole can of worms. If the application uses a custom authentication process, this feels like a more appropriate task for penetration testing. If a system under test uses RBAC (Role-Based Access Control), what role should the scanning user be granted? How is authentication handled in the case of MFA with a hardware token – there may be practical limits to this.
My view is that the need for authenticated scans should be left as a risk-based decision for the individual organizations being assessed.
Deadline for Responses
The deadline for RFC responses this time is 13 November 2020. That’s a total of less than 2 months to review and provide feedback. If you’re eligible to participate in the process, I strongly recommend you do so. This is one of the few opportunities you have to actually shape the standard you will ultimately be measured against, and many people do not have the option to participate.
When will I have to comply with v4.0?
Since PCI DSS v4.0 is still a draft standard you don’t need to worry about adjusting to it just yet. But, it is coming, so you should factor the v4.0 release timeline into your plans.
