Analysis of PCI DSS v4.0 – Part V: Requirements 7, 8 and 9

In this fifth instalment of the series “Analysis of PCI DSS v4.0” the changes applied to requirements 7, 8 and 9 of the standard in its new version (4.0) shall be analysed. These requirements – which are part of Group 4 “Implement Strong Access Control Measures” – are oriented towards the implementation and monitoring of physical and logical controls for the identification, authentication, authorisation and privilege management of system components that are part of the PCI DSS compliance environment to prevent unauthorised 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 that entity performs in the environment.

Before proceeding with the analysis of the changes applied to these requirements, it is important to remember the definitions of some terms used throughout the standard:

• The identification is the attribution of a unique identity to a person or system.
• The authentication is the process of verifying the identity of the user/system. By requesting access and submitting 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 that is known (something you know – SYK), as a password,
  • Something you have (something you have – SYH), such as a token or smart card (smart card),
  • Something that is (something you are -SYA), as a biometric control.
• The authorisation is the process of defining the specific resources a user/system needs (access) and determining privileges over those resources. The management of the authorisation should be based on the following criteria:
  • ‘Need to know» (Need-to-know) refers to providing access only to the least amount of data necessary to perform a job.
  • The "minimum privileges» (Least privileges) refer to providing only the minimum level of privileges necessary to perform a job.
  • The “separation of responsibilities” (Separation of duties) allow the division of mission critical functions between 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 using dual control and divided knowledge:
    • Dual control (dual control): A process that uses two or more separate entities (usually individuals) that operate in concert to protect sensitive functions or information. No single entity may access or use the material.
    • Divided knowledge (Split knowledge): Separation of data or information into two or more parts, each of which is constantly kept under the control of separately authorized persons or teams, so that no 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

Relationship between Authentication, Authorization and Identification

The management of these three concepts is called ‘Identity and access management’ (Identity and Access Management – IAM) and its implementing rules are assessed 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 the authorisation and privilege management. This requirement has traditionally been the requirement with fewer controls of the PCI DSS standard and so has continued in version 4.0 of the standard.

The changes implemented in this version are minimal and are mainly focused on clarifications and extension of their 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 suppliers 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 of this requirement do not apply to consumers (cardholders).
• Required a biannual review of all user accounts and their privileges to validate and confirm that these elements continue to be appropriate based on the roles and responsibilities defined to identify variations during the processes of high, low or changes during the life cycle of the accounts. The Directorate must recognize that access is adequate (req. 7.2.4) – This check will be valid from 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 allocation of privileges to these accounts must be based on the least privilege and their access must be limited to the systems, applications or processes that specifically require their use (req. 7.2.5) – This check will be valid from March 31, 2025.
  • Required a regular review of the implementation and system accounts to remedy any inappropriate access. The Directorate must recognize that access is adequate (req. 7.2.5.1) – This check will be valid from March 31, 2025.
  • Access to payment card data repositories must be through applications or programmatic methods based on roles and based on the least privilege, where only responsible administrators can execute direct queries to such repositories (req. 7.2.6). This control replaces PCI DSS v3.2.1 control 8.7, 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 everything” (deny all) continuous default 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 the authorisation 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:

• In PCI DSS version 4.0 the use of group, shared, generic or other shared authentication credentials will be allowed, as long as its use is made in an exceptional, justified way, approved by the Management, the individual who uses the account is identified before guaranteeing its access and that each activity can be related to the user who performed it. This change makes it possible to manage certain technical limitations (such as the use of the root account in Unix operating systems), where it was previously necessary to use compensatory control as an alternative to compliance.
• Several changes were made to the password policy:
  • Invalid authentication attempts were expanded from 6 to 10 (req. 8.3.4)
  • The password length was extended from 7 to 12 characters (or to 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 it is required to analyze the security posture of the account dynamically, determining access to resources automatically and in real time (req. 8.3.9). This requirement also applies to customer accounts of service providers, as of March 31, 2025 (req. 8.3.10.1)

Regarding the use of Multifactor 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 accesses to the CDE (access to the CDE cannot be obtained using a single authentication factor) (req. 8.4.2) – applicable from March 31, 2025.
• MFA is required for all remote network accesses originating from outside the corporate network (including accesses by users and administrators, as well as third parties and vendors) that may access or impact the CDE (req. 8.4.3)
• The 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 “skip” MFA controls if authorisation from the Directorate exists, is documented and allowed only within a limited timeframe (req. 8.5.1) – applicable from March 31, 2025.

In this regard, it is very important to highlight the concept of ‘MFA chains’ or multiple authentications using MFA depending on where the connection starts and ends. There may be cases where 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, the use of MFA is required twice.

Using MFA in PCI DSS v4.0

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

• When these accounts are used as an interactive account (used by an individual), it must be managed as an exception, it must be used within a defined time limit, it must be approved by the Management and the identity of the user must be confirmed, as well as tracking the actions of said user (req. 8.6.1)– applicable from March 31, 2025.
• On the other hand, the controls are extended to prevent the passwords used by these accounts from being insecurely integrated into scripts, configuration files or application source code (req. 8.6.2).
• The passwords used by these accounts must be changed periodically and have an appropriate complexity based on the periods defined for their change.

Requirement 9: Restrict Physical Access to Cardholder Data

Unlike the other requirements of the PCI DSS v4.0 standard, this is the only requirement whose name has not changed since version 3.2.1.  However, multiple clarifications were added to facilitate the implementation of controls, including:

• Definition of three physical areas where PCI DSS controls are applicable:
  • Sensitive areas (sensitive areas)
  • CDEcardholder data environment)
  • Installations (facilities)

Concepts of physical areas used in PCI DSS

• 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).
• The record of visits must include not only the name of the visitor and his company and the name of the person who authorizes his physical access, but also the date and time of the visit (req. 9.3.4).

With regard to the security of the points of interaction (POI), the following clarifications were added:

• Controls related to the physical security of the POI are not applicable to COTS devices (commercial off-the-shelf) – as they are commercially owned devices designed for distribution in mass markets – nor to components that allow manual entry of NAP data, such as a computer keyboard.
• The frequency of physical inspections carried out on POIs should be defined by the organisation on the basis of a risk analysis (req. 9.5.1.2.1) – applicable from March 31, 2025.

References

• Payment Data Security Essential: Secure Remote Access https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Infographic/Payment-Data-Security-Essential-Secure-Remote-Access.pdf
• Payment Data Security Essential: Strong Passwords https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Infographic/Payment-Data-Security-Essential-Strong-Passwords.pdf
• Multi-Factor Authentication Guidance https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Authentication/Multi-Factor-Authentication-Guidance-v1.pdf
• Skimming Prevention: Best Practices for Merchants https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Skimming%20Prevention/Skimming_Prevention_BP_for_Merchants_Sept2014.pdf
• Skimming Prevention: Overview of Best Practices for Merchants https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Skimming%20Prevention/Skimming_Prevention_At-a-Glance_Sept2014.pdf
• Skimming Resource Guide https://docs-prv.pcisecuritystandards.org/Guidance%20Document/Skimming%20Prevention/PCI_SSC_Skimming_Resource_Guide_v05.pdf