The Payment Card Industry (PCI) Standards Council has published a major update to the Data Security Standard (DSS), version 4.0. This version is an improvement over the current version, 3.2.1, which came out in 2018.
The new publication directs organizations that need to be compliant with the standard to
All of the items on the list above are good generic recommendations for any organization. Though PCI-DSS 4.0 was only recently published and will not fully take effect for up to three years, it’s never too early to suggest improvements. What follows is an examination of some of the provisions in PCI-DSS 4.0.
Section 1.4.4: “System components that store cardholder data are not directly accessible from untrusted networks.” The notion of trusted and untrusted networks is outdated and ineffective today. The principles of Zero Trust Architecture mandate proper authentication and authorization for each resource access attempt, regardless of source network or IP address. This is necessary, but not necessarily easy, to reduce risks of attacks that originate from what may have once been considered the trusted network. PCI-DSS 4.0 does refer to the NIST SP 800-207 but should have been more prescriptive about using Zero Trust as a basis for all aspects of implementation. 
Figure 1: How Zero Trust Spans Multiple Areas of IT
Section 2.2.2 provides guidance for how to manage and use vendor default accounts. These accounts are defined as “…accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults” (p.64). PCI-DSS 4.0 states that such passwords be changed in accordance with requirement 8.3.6, or to have inactive accounts disabled. Ideally, passwords should be eliminated with passwordless, risk-analysis-based, multi-factor authentication methods. For situations where service accounts with passwords still exist, PCI-DSS 4.0 should have mandated the use of Privileged Access Management solutions. The related technology of password vaults is mentioned in sections 8.2.3 and 8.6.2-3.
Section 4.2.1 mentions that exploits are available for old SSL and “early TLS” crypto. TLS 1.3 is the current version and should be at least recommended. Given the context around Point-of-Sale (POS) systems, we understand that full scale replacement of so many devices in the field will take some time.
Section 5.2.1-3 requires the use of anti-malware solutions on all systems that are at risk from malware. This leaves an out for systems that cannot run anti-malware agents or are not thought to be at risk: “Certain systems, at a given point in time, may not currently be commonly targeted or affected by malware. However, industry trends for malware can change quickly, so it is important for organizations to be aware of new malware that might affect their systems” (p. 115). KuppingerCole encourages the use of full Endpoint Protection Detection & Response (EPDR) solutions wherever possible. If for some reason components of your architecture don’t support EPDR agents, then use other controls and monitoring tools such as Network Detection & Response (NDR).
Section 8 pertains to “Processes and mechanisms for identifying users and authenticating access to system components” (p. 163). This section applies to employees, contractors, consultants, and other 3rd-parties, but intentionally does not address accounts held by consumers or cardholders. It loosely differentiates between identification and authentication. US NIST SP 800-63 is mentioned, but no clear processes for identity proofing or provisioning are defined. Group accounts are discouraged but not disallowed. Identity de-provisioning is required for terminated users, and user accounts must be at least disabled after 90 days of inactivity. Sessions should timeout after 15 minutes.
Section 8.3.3 says that a user identity must be verified before allowing modification to authentication factors. This is a good recommendation, but it is followed with an example of using Knowledge-Based Authentication (KBA) or using “security questions”. KBA is an extremely weak form of authentication and/or identification and should be avoided if possible.
Section 11.4 states that internal and external penetration testing should be performed every 12 months. Annual pen testing is insufficient. Organizations in this industry should instead use more state-of-the-art Attack Surface Management tools.
Section 11.5 calls for Intrusion Detection Systems to be used in critical areas. Network Detection & Response (NDR) tools are the more modern and effective alternatives.
PCI-DSS 4.0 does make some headway in prescribing security posture enhancements. Identity management components, though, are not as well defined as they should be. However, the reality is that the organizations that make up the payment services and broader financial services ecosystems are motivated to go beyond PCI-DSS to reduce the ever-present and seemingly ever-increasing risks of fraud. Moreover, members of the payment services and financial services industries have specifications from other industry consortia and differing regulations in various jurisdictions to consider when building and upgrading their infrastructure. Mappings and/or harmonizations between these specifications and regulations would be useful. Explicit references to governmental standards such as EU PSD2 (Strong Customer Authentication) and US NIST SP 800-63 (Authentication Assurance Levels) would be helpful as well.
Building compliant systems and then demonstrating compliance with specifications such as PCI-DSS requires effort and expense but are necessary to reduce fraud. For more information on how to choose solutions secure identity management systems (for both employees and consumers), Privileged Access Management systems, Fraud Reduction Intelligence Platforms, EPDR, and NDR tools, see our research.
