BLOG

Blog Post by Bruce Edwards, Senior Manager at Meditology Services

The PCI Security Standards Council has fielded an unprecedented amount of feedback in 2019 and 2020 related to the much-anticipated release of PCI DSS v4.0 due out early next year. There are several provisions that are proving controversial and generating a healthy debate about effective security controls to stem the torrent of payment card breaches.

This blog post provides an overview of some of the more controversial changes proposed in the new PCI standard set for release in 2021. I also provide my analysis relative to those requirements and recommendations for organizations to prepare for shifts in the v4.0 control requirements.

This is by no means a comprehensive review of the new standard or related comments; please review updates from the PCI Security Standards Council for a full run down of the proposed controls.

Password Controls (Requirement 8)

Password length and complexity has been a hot-button topic the last few years following NIST’s release of guidance on same. Specifically, the requirement to compare new passwords against a list of known, bad passwords has been touted as a more reliable protection mechanism than only requiring very long and complex passwords.

Our experience has been that a combination of reasonable-length passwords (e.g. 10+ characters) plus preventing easily guessable password creation is the optimal combination of controls. We believe including these requirements in the new PCI standard would go a long way toward broader adoption of these controls for the industry as a whole.

I recommend organizations look to implement both of these provisions in the interest of substantively reducing risks associated with password vulnerabilities, regardless of whether or not these end up as requirements in the new PCI standard.

Multi-Factor Authentication (Requirement 8)

The latest evolution of MFA controls includes a requirement for confirming all multi-factor authentication factors before providing any indication of success or failure of a factor. This would help address risks related to automated password guessing attacks.

This represents a change to the most common deployment models of MFA technologies, but one that would be a change for the better in my view. Healthcare organizations would do well to start asking their MFA providers if this functionality is available in the near term.

Authenticated Vulnerability Scans (Requirement 11)

Authentication scans can be conducted anonymously or using authenticated credentials (i.e. logged in with a valid username and password). Authenticated scans provide a much richer data set of vulnerabilities but can also be more time consuming and potentially disruptive to operations at times.

This is a tough one to weigh the pros and cons. Unauthenticated or anonymous scans will more accurately simulate the vulnerabilities that would be visible to most external attackers. They are also more efficient to run and less likely to have an adverse impact on production systems. However, authenticated scans can provide more accurate insights into system vulnerabilities to detect and resolve issues that might otherwise go unnoticed.

We will let the standards body make the final call on this one. From my perspective servicing the healthcare industry specifically, I suggest we err on the side of protecting patient safety and limiting the potential to adverse impact to production systems via unauthenticated scans to clinical systems while being open to authenticated scans for PCI and credit card applications.

Self-Signed Security Certificates (Requirement 4)

Self-signed security certificates allow organizations to encrypt card holder data in transit (e.g. SSL and VPNs connections) without having to rely on a third-party certificate authority to issue the certifications. Using a self-signed certification would technically address the PCI requirements for encryption but could expose the organization to risk of compromised self-signed certs, which often are created without expiration.

Third-party certificate authorities are a cornerstone of the trust model that runs modern Internet-based transmission of sensitive data. In my view, the sensitivity of card holder data is too high to allow self-signed certificates to be used for any Internet-facing transmission use cases.

Timing for Version 4.0 Release

PCI DSS v4.0 Draft v0.2 is scheduled for release this month or next month (Sept-Oct 2020) and will be made available for participating organizations, approved scanning vendors, and qualified security assessors. Another request for comment (RFC) period will ensue shortly thereafter.

The final release of v4.0 is scheduled for Q2 2021, which was pushed back from the original target of end of year 2020 due to the volume of feedback received in the initial RFC. Supporting documents, program, and training updates are scheduled to be development and released in Q4 2021.

Meditology provides PCI DSS assessments, scanning, and QSA services specifically for healthcare entities. Contact us to learn more or to discuss your specific circumstances and plans for PCI DSS adoption and compliance.