Impact of the new PCI 4.0 on the former 3.2.1 requirement 8 are in the form of : Reformulation, clarification, change/amendement, merge and move
Terminology:
New controls: 6 new controls:
Changes:
Amended:
Removed: None
Moved:
The requirement related to the protection of access to databases (3.2.1 - 8.7) has been moved to requirement 4.0-7.2.7
- The term "non-consumer users” is removed. This requirement do not apply to accounts used by consumers (cardholders).
- The term "authentication credentials" is replaced by "authentication factor"
New controls: 6 new controls:
- 4.0 - 8.1.2 Specifies that Roles and responsibilities for performing activities in requirement 8 shall be documented, assigned, and understood.
- 4.0 - 8.3.10.1 Additional requirement for service providers specifying an alternative to the periodic password change
- 4.0 - 8.4.2 Detail how MFA shall be implemented MFA ifor all access into the CDE.
- 4.0 - 8.6.1 Specifies how accounts used by systems or applications for interactive login, shall be managed.
- 4.0 - 8.6.2 Forbid hard coding of passwords/passphrases for any application and system accounts used for interactive login .
- 4.0 - 8.6.3 Specifies how Passwords/passphrases for any application and system accounts shall be protected.
Changes:
- 4.0 - 8.3.4 - The number of invalid authentication attempts before locking out a user ID jumps to 10!
- 4.0 - 8.3.6 - Password minimum length jumps to 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
- Instead of changing passwords/passphrases at least once every 90 days, organizations could determine access to resources automatically by dynamically analyzing the security posture of accounts.
- 4.0 - 8.2.2 Allows usage of group/shared accounts on an exceptional basis
Amended:
- 4.0 - 8.3.9 Provides an alternative to the periodic password change
- 4.0 - 8.2.6 - Require new/reset passwords/passphrases to be changed after first use
- 4.0 - 8.2.2 Specifies conditions for usage of group/shared accounts
Removed: None
Moved:
The requirement related to the protection of access to databases (3.2.1 - 8.7) has been moved to requirement 4.0-7.2.7
Get your PCI 4.0 COMPLIANCE DASHBOARD TOOL . Fully aligned with PCI DSS V4.0. It includes the defined approach requirements, the customized approach, applicability notes, purpose, good practices & further information, definition, example and defined testing procedures and prioritization approach. It also provides templates to register your compensating controls, controls met with remediations but also to register your customized Controls, the outcome of the customized approach risk assessments and the risk assessments for the definition of frequency periods as well as to register execution of vulnerability scans and penetration tests.
Detailed Analysis
Titre
3.2.1 - Identify and authenticate access to system components
4.0 - Identify Users and Authenticate Access to System Components
3.2.1 - Identify and authenticate access to system components
4.0 - Identify Users and Authenticate Access to System Components
3.2.1 - 8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.
Change: Reformulation
4.0 - 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.
Change: Reformulation
4.0 - 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.
8.1.2 - Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
Change: Reformulation + clarification
4.0 - 8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:
Change: Reformulation + clarification
4.0 - 8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:
- Authorized with the appropriate approval.
- Implemented with only the privileges specified on the documented approval.
3.2.1 - 8.1.3 Immediately revoke access for any terminated users.
Change: Reformulation
4.0 - 8.2.5 Access for terminated users is immediately revoked.
Change: Reformulation
4.0 - 8.2.5 Access for terminated users is immediately revoked.
3.2.1 - 8.1.4 Remove/disable inactive user accounts within 90 days.
Change: Reformulation
4.0 - 8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.
Change: Reformulation
4.0 - 8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.
3.2.1 - 8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access as follows:
4.0 - 8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:
- Enabled only during the time period needed and disabled when not in use.
- Monitored when in use.
4.0 - 8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:
- Enabled only during the time period needed and disabled when not in use.
- Use is monitored for unexpected activity.
3.2.1 - 8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts.
3.2.1 - 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
Change: Reformulation + merge + Change
4.0 - 8.3.4 Invalid authentication attempts are limited by:
3.2.1 - 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
Change: Reformulation + merge + Change
4.0 - 8.3.4 Invalid authentication attempts are limited by:
- Locking out the user ID after not more than 10 attempts.
- Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed
4.0 - 8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.
Change: Reformulation + Clarification
4.0 - 8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
Change: Reformulation + Clarification
4.0 - 8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
3.2.1 - 8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
4.0 - 8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
- Something you know, such as a password or passphrase
- Something you have, such as a token device or smart card
- Something you are, such as a biometric.
4.0 - 8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
- Something you know, such as a password or passphrase.
- Something you have, such as a token device or smart card.
- Something you are, such as a biometric element.
3.2.1 - 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.
Change: Reformulation
4.0 - 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
Change: Reformulation
4.0 - 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
3.2.1 - 8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys.
Change: Reformulation
4.0 - 8.3.3 User identity is verified before modifying any authentication factor.
Change: Reformulation
4.0 - 8.3.3 User identity is verified before modifying any authentication factor.
3.2.1 - 8.2.3 Passwords/passphrases must meet the following:
4.0 - 8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
- Require a minimum length of at least seven characters.
- Contain both numeric and alphabetic characters.
Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above.
4.0 - 8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
- A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
3.2.1 - 8.2.4 Change user passwords/passphrases at least once every 90 days.
Change: Reformulation + amendement + clarification
4.0 - 8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
Change: Reformulation + amendement + clarification
4.0 - 8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
- Passwords/passphrases are changed at least once every 90 days,
OR - The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
- Guidance for customers to change their user passwords/passphrases periodically.
- Guidance as to when, and under what circumstances, passwords/passphrases are to be changed.
3.2.1 - 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used.
Change: Reformulation
4.0 - 8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
Change: Reformulation
4.0 - 8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
3.2.1 - 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
Change: Reformulation + Amendement
4.0 - 8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
Change: Reformulation + Amendement
4.0 - 8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
- Set to a unique value for first-time use and upon reset.
- Forced to be changed immediately after the first use.
3.2.1 - 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
Change: Reformulation
4.0 - 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.
Change: Reformulation
4.0 - 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.
3.2.1 - 8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.
Change: Reformulation + clarification
4.0 - 8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
Change: Reformulation + clarification
4.0 - 8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
- All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
- All remote access by third parties and vendors.
3.2.1 - 8.4 Document and communicate authentication policies and procedures to all users including:
4.0 - 8.3.8 Authentication policies and procedures are documented and communicated to all users including:
- Guidance on selecting strong authentication credentials
- Guidance for how users should protect their authentication credentials
- Instructions not to reuse previously used passwords
- Instructions to change passwords if there is any suspicion the password could be compromised.
4.0 - 8.3.8 Authentication policies and procedures are documented and communicated to all users including:
- Guidance on selecting strong authentication factors.
- Guidance for how users should protect their authentication factors.
- Instructions not to reuse previously used passwords/passphrases.
- Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.
3.2.1 - 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
4.0 - 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
- Generic user IDs are disabled or removed.
- Shared user IDs do not exist for system administration and other critical functions.
- Shared and generic user IDs are not used to administer any system components.
4.0 - 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
- Account use is prevented unless needed for an exceptional circumstance.
- Use is limited to the time needed for the exceptional circumstance.
- Business justification for use is documented.
- Use is explicitly approved by management.
- Individual user identity is confirmed before access to an account is granted.
- Every action taken is attributable to an individual user.
3.2.1 - 8.5.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
Change: Reformulation
4.0 - 8.2.3 Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.
Change: Reformulation
4.0 - 8.2.3 Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.
3.2.1 - 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
4.0 - 8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:
- Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
- Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
4.0 - 8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:
- Factors are assigned to an individual user and not shared among multiple users.
- Physical and/or logical controls ensure only the intended user can use that factor to gain access.
3.2.1 - 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:
4.0 - 7.2.6
- All user access to, user queries of, and user actions on databases are through programmatic methods.
- Only database administrators have the ability to directly access or query databases.
- Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
4.0 - 7.2.6
3.2.1 - 8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
Change: Reformulation
4.0 - 8.1.1 All security policies and operational procedures that are identified in Requirement 8 are:
• Documented.
Change: Reformulation
4.0 - 8.1.1 All security policies and operational procedures that are identified in Requirement 8 are:
• Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
3.2.1 - None
Change: NEW
4.0 - 8.1.2 Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.
Change: NEW
4.0 - 8.1.2 Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.
3.2.1 - NONE
Change: NEW
4.0 - 8.3.10.1 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:
Change: NEW
4.0 - 8.3.10.1 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:
- Passwords/passphrases are changed at least once every 90 days,
OR - The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
3.2.1 - NONE
Change: NEW
4.0 - 8.4.2 MFA is implemented for all access into the CDE.
Change: NEW
4.0 - 8.4.2 MFA is implemented for all access into the CDE.
3.2.1 - NONE
Change: NEW
4.0 - 8.5.1 MFA systems are implemented as follows:
Change: NEW
4.0 - 8.5.1 MFA systems are implemented as follows:
- The MFA system is not susceptible to replay
attacks. - MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
- At least two different types of authentication factors are used.
- Success of all authentication factors is required before access is granted.
3.2.1 - NONE
Change: NEW
4.0 - 8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed as follows:
Change: NEW
4.0 - 8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed as follows:
- Interactive use is prevented unless needed for an exceptional circumstance.
- Interactive use is limited to the time needed for the exceptional circumstance.
- Business justification for interactive use is documented.
- Interactive use is explicitly approved by management.
- Individual user identity is confirmed before access to account is granted.
- Every action taken is attributable to an individual user.
3.2.1 - NONE
Change: NEW
4.0 - 8.6.2 - Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. 3.2.1 - NONE
Change: NEW
4.0 - 8.6.2 - Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. 3.2.1 - NONE
3.2.1 - NONE
Change: NEW
4.0 - 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:
Change: NEW
4.0 - 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:
- Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.
- Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.
RSS Feed
