PCI DSS 4.0 – Major New and Updated Requirements

Part 3 of the PCI DSS 4.0 Launch Series

The content of this blog is based solely on the PCI Data Security Standard (DSS) version 4.0 and related validation documents and does not incorporate any additional clarification/guidance provided by the PCI Security Standards Council (SSC) after the date of this blog.

Version 4.0 of the PCI DSS represents a badly-needed overhaul of the standard to become more technology-agnostic and better align with today’s threat landscape.  It includes multiple new and updated requirements, many of which we will highlight here.  Some of these requirements close (or open…) “security loopholes” from previous versions; others simply represent more effective ways to protect cardholder data.

• Arguably the most important change is the addition of Req. 12.5.2, which states that the entity’s PCI scope must be documented and confirmed by the entity annually.  It has never been possible for an entity to achieve and maintain compliance without doing this, but the only place to which this was alluded previously was in the early sections of the ROC template. 
• The second requirement in each Requirement section explicitly mandates that roles and responsibilities for performing required compliance activities be “documented, assigned, and understood.”  This requirement was implied in prior versions, given that policies and procedures had to be “known to all affected parties,” but these new requirements codify the approach further.
• A firewall (now called “network security controls,” or NSCs in order to incorporate modern technologies) is now required between all wireless networks and the CDE, EVEN IF the wireless network is part of the CDE (Req. 1.3.3).
• Entities are now required to implement measures to prevent unintended receipt of cardholder data (Req. 4.2.2) and to review offline media backup security annually (Req. 9.4.1.1).
• The use of group/shared/generic accounts is now allowed on a very limited basis, with strict parameters (Req. 8.2.2).  Modern IAM solutions should make this relatively easy to support.
• The multi-factor authentication (MFA) requirement (Req. 8.4.3) clearly includes remote access to connected-to in-scope environments as well.
• The 90-day password change requirement (Req. 8.3.9) has been amended to include this option:  “The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.”  While this may seem to be a bit of a “get out of jail free card,” the reality is that the additional MFA requirements limit the scope of this requirement.
• External vulnerability scans must be completed after significant changes (Req. 11.3.2.1).  The entity doing this scanning does not have to be an Approved Scanning Vendor (ASV).
• In addition to exploitable vulnerabilities, ”security weaknesses” identified during penetration testing must also be corrected (Req. 11.4.4).  The term “security weaknesses” is not defined in the new Glossary, so we expect some clarification from the Council on this one.

In addition, a couple of requirements have been updated to clarify a couple of service provider-related items.  Req. 3.6.1.1 makes it crystal-clear that cryptographic architecture is a shared responsibility between the entity and the cloud provider(s).  Req. 12.9.2 explicitly mandates that service providers provide PCI compliance status information and a responsibility matrix to in-scope customers upon request, removing some ambiguity from what is now Reqs. 12.8.4 and 12.8.5.

Several requirements mandate that an activity be conducted “periodically,” as opposed to a more specific internal (annually, quarterly, etc.).  Version 4.0 defines “periodically” as follows:

Frequency of occurrence is at the entity’s discretion and is documented and supported by the entity’s risk analysis. The entity must demonstrate that the frequency is appropriate for the activity to be effective and to meet the intent of the requirement. 

The “entity’s risk analysis” in this case is the targeted risk analysis required by Req. 12.3.1, which is a future-dated requirement.  However, there are several requirements in force immediately (5.2.3, 9.4.1.2, 9.5.1, 10.4.2, and 12.10.4) which require “periodic” execution without being more specific on timeframe.  Therefore, the targeted risk analysis really needs to be completed immediately in order to justify the timeframes used for these five requirements out of the gate.

All of the above requirements are in play immediately for any entity assessing under version 4.0.  In part 4 of this blog series, we’ll dive into some of the future-dated requirements in Version 4.0 – those requirements that will not have to be in place before your first 4.0 assessment, but very soon thereafter.