Analysis of PCI DSS v4.0 - Part 5: Requirements 7, 8 & 9

Our fifth article in the PCI DSS v4.0 analysis series examines the changes made to requirements 7, 8, and 9 of the standard.

In group 4 "Implement Strong Access Control Measures," these requirements focus on implementing and monitoring physical and logical controls to identify, authenticate, authorize, and manage privileges throughout the system and are part of the PCI DSS compliance environment to prevent unauthorized access, control the confidentiality, integrity, and availability of assets and enable the relationship between an entity (a person or a computer system) and the actions that entity performs in the environment.

Click here to read the Analysis of DSS DSS v4.0

Part 4: Requirements 3 & 4

As we analyze the changes applied to these requirements, it is important to remember the definitions of some terms used throughout the standard:

• Identification is the attribution of a unique identity to a person or system.
• Authentication is the process of verifying the identity of the user/system. By requesting access and presenting a unique user/system ID, the user/system provides a set of private data to which only the user/system has access or knowledge. Validation of one or more of the following factors is used for this process:
  • Something You Know (SYK), such as a password
  • Something You Have (SYH), such as a token, a digital certificate, or a smart card
  • Something You Are (SYA), like a biometric control
• Authorization is the process of defining the specific resources a user/system needs (access) and determining privileges over those resources. Authorization management should be based on the following criteria:
  • "Need-to-know" refers to providing access to only the smallest amount of data necessary to perform a job.
  • "Least privileges" refers to providing only the minimum level of privileges necessary to perform a job.
  • "Separation of duties" allows mission-critical functions to be divided among different individuals and/or functions, defines roles and responsibilities for each individual or role, and ensures that security personnel who manage access control functions do not also manage audit functions to avoid conflicts of interest by employing dual control and divided knowledge:
    • Dual Control: A process that uses two or more separate entities (usually individuals) operating in concert to protect sensitive functions or information. No single entity can access or use the material.
    • Split knowledge: Separation of data or information into two or more parts, each of which is kept constantly under the control of separate authorized persons or teams, so that no one person or team knows the whole of the data.

The relationship between these three important concepts is simple:

• Identification provides uniqueness
• Authentication provides validity
• Authorization provides control
  
  

The management of these three concepts is called "Identity and Access Management" (IAM) and its implementation rules are evaluated in the controls of these three PCI DSS requirements.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Requirement 7 defines the criteria for authorization and privilege management. This requirement has traditionally been the requirement with fewer controls in the PCI DSS and has continued to be so in version 4.0 of the standard.

The changes implemented in this version are minimal and are mainly focused on clarifications and expansion of its applicability.

• It is explicitly clarified that this requirement applies to interactive accounts (associated with a particular user) and access by employees, contractors, internal and external providers, and other third parties. Certain controls also apply to application and system accounts used by the entity (also called "service accounts", used for connection between applications without direct interaction with a person)
• It is clarified that the controls in this requirement do not apply to consumers (cardholders).
• A semi-annual review of all user accounts and their privileges is required to validate and confirm that these elements continue to be appropriate based on defined roles and responsibilities to identify variations during the lifecycle of the accounts. Management must acknowledge that access is appropriate (req. 7.2.4) - This control will be valid as of March 31, 2025
• The applicability of this requirement is extended to cover not only interactive user accounts but also application and system accounts. To this end:
  • The assignment of privileges to these accounts must be based on the least privilege and their access must be limited to systems, applications, or processes that specifically require their use (req. 7.2.5) - This control will be valid as of March 31, 2025
  • A periodic review of application and system accounts is required to remediate any inappropriate access. Management must acknowledge that access is appropriate (req. 7.2.5.1) - This control will be valid from March 31, 2025
  • Access to payment card data repositories should be through role-based, least privilege-based applications or programmatic methods, where only responsible administrators can execute direct queries to such repositories (req. 7.2.6)
  • This control replaces control 8.7 of PCI DSS v3.2.1, clarifying that access is not only to databases but to any card data repository.

The controls associated with the existence of an access control system for the environment configured to "deny all" by default continue without major changes in this new version of the standard.

Requirement 8: Identify Users and Authenticate Access to System Components

As a complement to the management of authorization processes described in requirement 7, requirement 8 establishes the criteria for the identification and authentication of users, systems, and/or applications.

Among the most relevant changes to this requirement are the following:

• In PCI DSS version 4.0, the use of group, shared, generic or other shared authentication credentials will be permitted, as long as their use is exceptional, justified, approved by management, and the individual using the account is identified before access is granted, and each activity can be linked to the user who performed it. This change makes it possible to manage certain technical limitations (such as the use of the "root" account on Unix operating systems), where previously it was necessary to use compensating control as a compliance alternative
• Several changes were made to the password policy:
  • Invalid authentication attempts extended from 6 to 10 (req. 8.3.4)
  • Password length was extended from 7 to 12 characters (or 8, if the system does not support 10 characters) (req. 8.3.6)
  • In the event that the password is used as the only access factor, these passwords must be changed every 90 days, or the security posture of the account is required to be dynamically analyzed, determining access to resources automatically and in real-time (req. 8.3.9). This requirement also applies to service provider customer accounts as of March 31, 2025 (req. 8.3.10.1)

Regarding the use of multi-factor authentication (MFA), the changes included in version 4.0 are as follows:

• MFA is required for all non-console access (access made using a network interface instead of a direct physical connection) to the CDE by personnel with administrative access (req. 8.4.1)
• MFA is required for all access to the CDE (access to the CDE cannot be obtained using a single authentication factor) (req. 8.4.2) - applicable as of March 31, 2025
• MFA is required for all remote network access originating from outside the corporate network (including access by users and administrators, as well as third parties and vendors) that may access or impact the CDE (req. 8.4.3)
• Technical configurations to be implemented in MFA are described, including controls to prevent replay attacks, use of at least two different authentication factors, correct validation of all authentication factors before granting access to the resource/network, and restrictions to "bypass" MFA controls if authorized by management, documented, and allowed only in a limited time window (req. 8.5.1) - applicable as of March 31, 2025

In this sense, it is very important to highlight the concept of "MFA chains" or multiple authentications using MFA depending on where the connection starts and where it ends. There may be cases in which an administrator connects from outside the corporate network to a network that may impact the CDE (first use of MFA) and, once there, requires a network connection to the CDE (second use of MFA). In these cases, MFA is required twice.

Finally, the controls that must be applied to any system or application account are also described:

• When these accounts are used as an interactive account (used by an individual), it must be managed as an exception, must be used within a defined time limit, must be approved by management, and must confirm the user's identity and track the user's actions (req. 8.6.1)-applicable as of March 31, 2025
• On the other hand, controls are extended to prevent passwords used by these accounts from being insecurely embedded in scripts, configuration files, or application source code (req. 8.6.2)
• Passwords used by these accounts should be changed periodically and have an appropriate complexity based on the defined periods for change
  
  

Requirement 9: Restrict Physical Access to Cardholder Data

Unlike the other requirements in PCI DSS v4.0, this is the only requirement whose name is unchanged from version 3.2.1.

However, multiple clarifications were added to facilitate the implementation of the controls, including:

• Definition of three physical areas where PCI DSS controls are applicable:
  • Sensitive areas
  • CDE (cardholder data environment)
  • Facilities
    
    

• The procedures to be applied to the life cycle of the management of physical access to the CDE by employees (req. 9.3.1) and visitors (req. 9.3.2) are differentiated
• The visitor log should include not only the name of the visitor and his/her company and the name of the person authorizing physical access but also the date and time of the visit (req. 9.3.4)

Regarding the safety of points of interaction (POI), the following clarifications were added:

• Controls related to the physical security of the POI do not apply to COTS (commercial off-the-shelf) devices - as they are commercially owned devices designed for mass market distribution - or to components that allow manual entry of PAN data, such as a computer keyboard
• The frequency of physical inspections performed on POIs shall be defined by the organization based on risk analysis (req. 9.5.1.2.1) - applicable as of March 31, 2025

New to the Analysis of PCI DSS v4.0 series by Advantio? Follow the links below to catch up on the previous articles:

• Part 1: Introduction
• Part 2: Requirements 1 & 2
• Part 3: Requirements 3 & 4
• Part 4: Requirements 5 & 6

References:

• Payment Data Security Essential: Secure Remote Access
• Payment Data Security Essential: Strong Passwords
• Multi-Factor Authentication Guidance
• Skimming Prevention: Best Practices for Merchants
• Skimming Prevention: Overview of Best Practices for Merchants
• Skimming Resource Guide